Сброс пароля по электронной почте без таблицы базы данных

Question

Обычный процесс сброса пароля пользователя по почте такой:

1. Создать случайную строку и сохранить ее в таблице базы данных
2. Отправить по электронной почте пользователю
3. Пользователь нажимает на ссылку, содержащую строку
4. Строка проверяется в базе данных; если это соответствует, пользовательский pw сбрасывается

Однако поддержание таблицы, истечение срока действия старых строк и т. Д. Кажется излишним хлопотом. Есть ли какие-либо очевидные недостатки в этом альтернативном подходе?

1. Создать MD5-хэш существующего пароля пользователя
2. Отправить хэш-строку пользователю
3. Пользователь нажимает на ссылку, содержащую строку
4. Строка проверяется повторным хэшированием существующего pw; если это совпадает, пользователь pw сбрасывается

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

И да, есть один очевидный «недостаток»: сгенерированная таким образом ссылка сброса не истечет, пока пользователь не изменит свой пароль (щелкнув ссылку). Я действительно не понимаю, почему это было бы проблемой - если почтовый ящик скомпрометирован, пользователь все равно облажался. И нет риска повторного использования, поскольку после изменения пароля пользователя ссылка для сброса больше не будет совпадать.

Answer 1

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

Answer 2

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

Answer 3

На самом деле, подумав об этом снова, ваш метод потенциально менее безопасен, чем "Нормальный поток".

Если вы просто отправите обратно HASH(HASH(user's original password)), я могу увидеть сценарии, в которых это может дать атакующему рычаги:

Сценарий 1:

1. Jim регистрируется на вашем сайте как jimjones@microsoft.com.
2. Jim запрашивает сброс пароля, но не использует его. Письмо о сбросе осталось навсегда в его почтовом ящике.
3. Jim меняет свой адрес электронной почты на вашем сайте.
4. jimjones@gmicrosoft.com скомпрометировано Bob.
5. Bob теперь выполняет грубую атаку через свою распределенную ферму GPGPU и восстанавливает пароль Jim.

Сценарий 2:

1. Jim использует пароль jimjonesupinthisma! для своего банковского счета.
2. Jim регистрируется на вашем сайте как jimjones@microsoft.com. jimjones@microsoft.com - это , а не , никак не связанный с банковским счетом Jim.
3. jimjones@gmicrosoft.com скомпрометирован Bob.
4. Bob теперь запрашивает сброс, теперь у него HASH(HASH(jim's password)).
5. Bob теперь выполняет грубую атаку через свою распределенную ферму GPGPU и восстанавливает пароль Jim, который он затем использует для доступа к банковскому счету Jim.

Сценарий 3:

(Ваш сайт использует TLS, пользователи регистрируются через TLS.)

1. Jim регистрируется на вашем сайте как jimjones@microsoft.com.
2. Bob запрашивает сброс пароля для учетной записи Jim.
3. Bob работает для АНБ в Комната 641A .
4. Bob использует свой глобальный интернет-сниффер и получает HASH(HASH(jim's password)) в виде открытого текста на jimjones@microsoft.com.
5. Bob теперь выполняет грубую атаку через свою распределенную ферму GPGPU и восстанавливает пароль Jim.

Варианты сценариев 1 и 2 происходят постоянно (в зависимости от того, насколько сильны хеш и пароль), я не уверен насчет 3. Суть в том, что ваш метод извлекает ненужную информацию, которая действительно может использовать атакующего против вашего пользователя.

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

Answer 4

Только что прошел мимо этого выпуска и есть идея:

1) Выпуск JWT (Json Web Token) с информацией об учетной записи пользователя. Срок действия токена истекает, скажем, 1 час.

2) Отправьте токен пользователю по электронной почте / по ссылке

3) Пользователь щелкает ссылку, токен отправляется на конечную точку сервера, токен проверяется. Если он действителен, вы распаковываете токен и обновляете учетную запись пользователя

Есть ли недостатки в этом подходе? База данных не затрагивается (за исключением новых пользовательских паролей, если необходимо)

Answer 5

скажем, в очень редком случае, у двух ваших пользователей был один и тот же хешированный пароль, даже после объединения в него случайной соли; была бы проблема, верно? Я думаю, это не помешало бы, если бы вы добавили адрес электронной почты или Hashid user_id к ссылке для сброса пароля.