Изменение пароля: Лучшая практика

Question

Я пишу первое веб-приложение Baby's. Моя первая задача состояла в том, чтобы настроить систему проверки подлинности, и я думаю, что все в порядке. Я новичок во всем этом, поэтому:

Когда пользователь сообщает, что он забыл свой пароль, я отправляю ему временный пароль для замены в виде обычного текста. Возможно, это не самый безопасный способ справиться с ситуацией, но сейчас я это делаю. Я заставляю его изменять его при следующем входе в систему, и используемая вами техника заключается в переносе поля «обязательное изменение» в базе данных, значение true для пользователей, которым было отправлено электронное письмо.

Мой вопрос: Является ли отдельная колонка базы данных лучшей тактикой в ​​данных обстоятельствах или есть что-то лучшее, что я могу сделать?

Answer 1

Отдельная колонка вполне разумна.

Операционные системы обычно имеют поле «Время истечения срока действия пароля», которое удваивается, поскольку флаг «должен измениться при следующем входе в систему», просто установив метку времени на 0 (AKA 1 января 1970 года). Веб-сайты обычно не имеют дат истечения срока действия пароля, и в этом случае достаточно простого логического флага.

Answer 2

Предполагаю, что вы храните пароли хэшированных и соленых. Если нет, сделайте это. Если это так, вы можете хранить метаданные в соли. Например. соль составляет [0-9a-z]{8}, но для временных паролей это ____[0-9a-z]{4}. (прежде чем downvoting, люди, читайте дальше!) Дело в том, что отдельное поле может быть отредактировано отдельно от хэш-поля. Конечно, должен никогда не бывает, но это может. (неудачные запросы, мошеннические системные администраторы, люди, которые обнаружили phpmyadmin и считают, они понимают систему и т. д.) Сохранение «состояния» пароля в соли предотвращает такой хаос: при проверке пароля вы всегда сможете чтобы убедиться, что вы подтвердили пароль временного пароля, и вы всегда сможете указать пользователя, которому нужно получить приглашение «ввести новый пароль». всегда.

Answer 3

Моя практика всегда заключалась в том, чтобы перегрузить проверку подлинности электронной почты (где вы отправляете электронное письмо владельцу регистрации, чтобы убедиться, что владелец регистрации владеет адресом) также функционирует как механизм сброса пароля. Я использую определенную информацию о пользователе (имя пользователя, идентификатор, адрес электронной почты, и, что важно, текущий хэш пароля в БД), чтобы сделать хэш, который включен в URL-адрес, отправленный пользователю по электронной почте, после чего они могут установить новый пароль по их выбору.

Это, как говорится, «лучшая практика» по отношению к аутентификации пользователя - это 95% времени для пользователя библиотеки, которую кто-то еще написал и протестировал широко. Просто найдите Google, который подходит для вашей инфраструктуры.