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

Question

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

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

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

Answer 1

Разумно использовать отдельный столбец.

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

Answer 2

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

Answer 3

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

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