Хороший безопасный способ запомнить флажок пользователя

У меня есть страница входа в систему, которая запрашивает имя пользователя и пароль. На этой странице есть флажок «Запомнить меня».

Аутентификация: для предоставленного имени пользователя преобразуйте предоставленный пароль в хеш, используя соль, хранящуюся с записью пользовательской базы данных, и сравните хеш с сохраненным хешем.

Когда пользователь ставит галочку, что мне следует сохранить в его cookie, чтобы они автоматически входили в систему при следующем посещении?

Я подумал, что хороший способ - сохранить их имя пользователя и хешированное значение пароля в файле cookie и повторно аутентифицировать пользователя при его следующем посещении. Соль будет храниться в базе данных.


person Valamas    schedule 23.11.2011    source источник


Ответы (3)


Это зависит от уровня безопасности, который вы хотите поддерживать. Когда я устанавливаю флажок «Запомнить меня», я хочу, чтобы он запомнил только мое имя пользователя. Я по-прежнему хочу указать свой пароль как обычно.

Мне кажется плохой идеей хранить имя пользователя и хешированный пароль в файле cookie.

person Craig T    schedule 23.11.2011
comment
@Valamas, как указал Крейг, хранить пароль (хешированный или нет) в cookie - плохая идея. Вы не получите от этого ничего лишнего. Вместо этого сохраните имя пользователя и отметку времени в зашифрованном виде в файле cookie. Наличие этого токена по сути говорит вам, что ваш пользователь прошел индивидуальную аутентификацию. Кроме того, в ASP.NET Forms Authentication все это уже встроено, поэтому вам действительно не придется изобретать колесо заново. Используйте параметр persistCookie. - person VinayC; 23.11.2011
comment
@VinayC: Это не первый раз, когда вы хорошо помогаете мне с проверкой подлинности с помощью форм. Теперь я правильно подключил его в своем классе FormsAuthenticationService. Спасибо - person Valamas; 23.11.2011

Я бы не стал хранить хешированные пароли в клиентских файлах cookie. Я бы создал еще одну абстракцию между пользователями и долгоживущими сеансами. Я бы начал с чтения следующей статьи, чтобы получить представление о задачах:

http://fishbowl.pastiche.org/2004/01/19/persistent_login_cookie_best_practice/

Ключевой момент из этой статьи заключается в том, что не все логины должны быть одинаковыми.

person J. Holmes    schedule 23.11.2011
comment
Хорошая статья. Вам вообще не нужно помещать имя пользователя в файл cookie, вам просто нужно большое случайное число. Имя пользователя и временная метка могут быть на стороне сервера. - person Cameron Skinner; 23.11.2011
comment
@CameronSkinner Я думаю, он говорит, что имена пользователей особенно секретны, поэтому вероятность столкновения меньше. Если бы это было просто большое случайное число, то теоретически вы могли бы спамить сервер и попытаться войти в систему как кто угодно ... Даже если бы у вас был правильный ключ, вам нужно было бы вставить его в нужную дверь. - person J. Holmes; 23.11.2011
comment
Я подозревал, что кто-то будет возражать против этого :) Вы можете всегда спамить сервер и попытаться войти в систему как любой. Внесение имени пользователя в файл cookie не предотвращает этого и лишь незначительно увеличивает пространство, необходимое злоумышленнику для выборки. Вы можете думать о имени пользователя как о добавлении очень низкой энтропии к большому случайному числу. Если вы добавляете, скажем, 10 байтов в файл cookie для хранения имени пользователя, почему бы вместо этого просто не добавить 10 байтов случайности? Тогда вы искренне уменьшите вероятность столкновений. Ключевым моментом здесь является то, что злоумышленник угадывает информацию, поэтому сделайте это как можно более случайным. - person Cameron Skinner; 24.11.2011

Если вы действительно хотите, чтобы пользователь вошел в систему, вам следует сохранить уникальный токен входа в файл cookie, а не имя пользователя или хешированный пароль. Когда ваш сервер получает токен входа в систему, вы можете сравнить его с вашей базой данных пользователей, постоянно вошедших в систему, и увидеть, какому пользователю соответствует токен. Сервер должен хранить токен входа, имя пользователя, связанное с этим токеном, и время истечения срока действия. После использования токен должен быть признан недействительным, чтобы его нельзя было использовать повторно.

Это сводит к минимуму утечку информации клиенту и ограничивает возможности злоумышленника восстановить пароль законного пользователя, если ему удастся украсть файл cookie (что относительно легко сделать).

Я настоятельно рекомендую вам также установить флаг безопасности для всех ваших файлов cookie, чтобы они отправлялись только через безопасные соединения, и убедитесь, что у вас есть относительно короткий тайм-аут для постоянных входов в систему. Кроме того, рекомендуется провести дополнительные проверки авторизации, например убедиться, что токен входа в систему связан с определенным IP-адресом или отпечатком пальца браузера, чтобы предотвратить случайные атаки. Это по-прежнему не будет серьезно мешать решительному злоумышленнику, но может отговорить некоторых скрипачей.

Наконец, подумайте о том, чтобы воспользоваться советом @Craig T и запомнить только имя пользователя, а не сохранять пользователя в системе. Постоянные входы в систему очень опасны, поэтому вам следует тщательно подумать о пользе, которую ваши пользователи получат от этого, по сравнению с потенциальными затратами.

Молодец, что правильно храните пароли в своей БД! Удивительно, сколько людей думают, что им не нужны соли.

person Cameron Skinner    schedule 23.11.2011
comment
Отлично. +1 к защищенному свойству - сейчас я настрою https-версию сайта разработки, чтобы гарантировать это. - person Valamas; 23.11.2011