Вариант номер раз - используем обычные куки (cookie).
После логина, сервер сообщает браузеру, что надо установить cookie, которые содержат логин/пароль в зашифрованном виде (об шифровании позже).
В следующий раз браузер сам отправит серверу куки и сервер, обработав их, автоматически залогинит.
В этом варианте на флеше или вообще ничего делать не надо, или надо по минимуму. В основном тут будут задействованы сервер и браузер.
Про недостатки, надеюсь, скажет кто-нибудь другой.
Вариант номер два - используем флешевский SharedObject.
Идея та же самая, но в этом случае мы не полагаемся на браузер, а делаем всё самостоятельно.
После логина получаем от сервера некоторые зашиврованные данные и созраняем в SharedObject.
В следующий раз, если обнаруживаем, в SharedObject уже что-то лежит, не предлагаем пользователю ввести имя/пароль, а сразу отправляем эти зашифрованные данные.
Тут уже попрограммировать придётся побольше, но зато мы сами контролируем процесс, настройки браузера нас мало волнуют (зато волнуют настройки флеш-плеера
).
Про недостатки тоже кто-нибудь обязательно напишет, тут это умеют.
Теперь по поводу того, как шифровать.
Нам нужно зашифровать пару логин-пароль таким образом, чтобы сервер мог проверить, что они действительно соответствуют друг другу и в БД есть такой аккаунт. И при этом никто левый не мог бы расшифровать.
Идеальный вариант - если данные вообще нерасшифровываемые.
Обычно для этого используют необратимую хеш-функцию, чаще всего - MD5.
На самом деле, не такая уж она и не обратимая, но это уже отдельная длинная беседа.
Вобщем, самый наипростейший принцип такой: логин хранится в чистом виде, а вот вместо пароля хранится его MD5-хеш. На сервере тоже пароль в виде MD5-хеш.
Флешка (или браузер) отправляет логин и хеш. Сервер по логину смотрит в базе данных, какой хеш соответствует этому логину. Если совпали - значит всё замечательно. Если нет - значит пароль бы неверный.
Это так, в кратце и популярным языком.