Как реализовать сбросы пароля?

Я работаю над приложением в ASP.NET и задавался вопросом конкретно, как я мог реализовать a Password Reset функционируйте, если я хотел прокрутить свое собственное.

А именно, у меня есть следующие вопросы:

  • Что такое хороший способ генерировать Уникальный идентификатор, который трудно взломать?
  • Должен быть таймер, присоединенный к нему? Если так, какой длины это должно быть?
  • Я должен записать IP-адрес? Это даже имеет значение?
  • Для какой информации я должен запросить под экраном "Password Reset"? Просто Адрес электронной почты? Или возможно адрес электронной почты плюс некоторая информация, которую они 'знают'? (Любимая команда, имя щенка, и т.д.)

Есть ли какие-либо другие соображения, о которых я должен знать?

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

Править: Будут цениться ответы, которые также входят, как такая таблица была бы смоделирована и обработана в SQL Server или любых ссылках MVC ASP.NET на ответ.

81
задан 7 revs, 2 users 73% 23 May 2017 в 12:02
поделиться

6 ответов

Много хороших ответов здесь, я беспокойство привычки, повторяющее все это...

За исключением одной проблемы, которая повторяется почти каждым ответом здесь, даже при том, что его несправедливость:

Гуиды (реалистично) уникальны и статистически невозможны предположить.

Это не верно, GUID являются очень слабыми идентификаторами и не должны использоваться для предоставления доступа к учетной записи пользователя.
При исследовании структуры Вы получаете в общей сложности 128 битов в больше всего..., который не рассматривают много в наше время.
Из которого первая половина является типичным инвариантом (для генерирующейся системы), и половина того, что оставляют, иждивенец времени (или что-то еще подобное).
В целом, это - очень слабое и легко bruteforced механизм.

Не используйте это!

Вместо этого просто используйте криптографически сильный генератор случайных чисел (System.Security.Cryptography.RNGCryptoServiceProvider), и получите по крайней мере 256 битов необработанной энтропии.

Все остальные, как многочисленные другие предоставленные ответы.

66
ответ дан Machado 24 November 2019 в 09:38
поделиться

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

, В конце концов, если пользователи emailbox был поставлен под угрозу (т.е. хакер имеет вход в систему/пароль для адреса электронной почты), нет очень, можно сделать об этом.

3
ответ дан E.J. Brennan 24 November 2019 в 09:38
поделиться

Вы могли послать электронное письмо пользователю со ссылкой. Эта ссылка содержала бы некоторых трудно для предположения строки (как GUID). На стороне сервера Вы также сохранили бы ту же строку, как Вы отправили пользователю. Теперь, когда пользователь нажимает на ссылке, можно найти в записи дб с той же строкой секретного ключа и изменить ее пароль.

2
ответ дан Sergej Andrejev 24 November 2019 в 09:38
поделиться

РЕДАКТИРОВАНИЕ 22.05.2012: Как продолжение этого популярного ответа, я больше не использую GUID сам в этой процедуре. Как другой популярный ответ, я теперь использую свой собственный алгоритм хеширования для генерации ключа для отправки в URL. Это имеет преимущество того, чтобы быть короче также. Изучите Систему. Безопасность. Криптография для генерации их, которые я обычно использую СОЛЬ также.

Во-первых, сразу не изменяйте пароль пользователя.

Во-первых, сразу не изменяйте пароль пользователя, когда они запросят это. Это - нарушение защиты, поскольку кто-то мог предположить адреса электронной почты (т.е. Ваш адрес электронной почты в компании) и изменить пароли в прихоти. Лучшие практики в эти дни обычно включают ссылку "подтверждения", отправленную в адрес электронной почты пользователя, подтверждая, что они хотят сбросить его. Эта ссылка состоит в том, где Вы хотите отправить ссылку уникального ключа. Я отправляю мой со ссылкой как: domain.com/User/PasswordReset/xjdk2ms92

Да, установите тайм-аут на ссылке и сохраните ключ и тайм-аут на Вашем бэкенде (и соль при использовании одного). Тайм-ауты 3 дней являются нормой, и удостоверьтесь, что уведомили пользователя 3 дней на веб-уровне, когда они запрашивают сбросить.

Используйте уникальный ключ хеша

Мой предыдущий ответ, который, как сказали, использовал GUID. Я теперь редактирую это, чтобы советовать всем использовать случайным образом сгенерированный хеш, например, использование RNGCryptoServiceProvider. И, удостоверьтесь, что устранили любые "реальные слова" из хеша. Я вспоминаю специальный телефонный вызов 6:00 того, где женщина получила определенное "c" слово в ней, "предполагают, чтобы быть случайным" хешированным ключом, который сделал разработчик. Doh!

Вся процедура

  • Пользователь нажимает пароль "сброса".
  • Пользователя просят относительно электронного письма.
  • Пользователь вводит электронную почту, и щелчки отправляют. Не подтверждайте или отклоняйте электронную почту, поскольку это - плохая практика также. Просто скажите, "Мы отправили запрос сброса пароля, если электронная почта проверяется". или что-то загадочное одинаково.
  • Вы создаете хеш из RNGCryptoServiceProvider, сохраните его как отдельный объект в ut_UserPasswordRequests таблица и ссылка назад на пользователя. Так это так можно отследить старые запросы и сообщить пользователю, что истекли более старые ссылки.
  • Отправьте ссылку на адрес электронной почты.

Пользователь получает ссылку, как http://domain.com/User/PasswordReset/xjdk2ms92 , и щелчки это.

Если ссылка проверяется, Вы просите новый пароль. Простой, и пользователь добирается для установки их собственного пароля. Или, установите свой собственный загадочный пароль здесь и сообщите им об их новом пароле здесь (и пошлите его по электронной почте им).

67
ответ дан Robert 24 November 2019 в 09:38
поделиться

Во-первых, мы должны знать то, что Вы уже знаете о пользователе. Очевидно, у Вас есть имя пользователя и старый пароль. Что еще Вы знаете?У вас есть электронная почта? У Вас есть данные относительно любимого цветка пользователя?

Принятие Вас имеет имя пользователя, пароль и рабочий адрес электронной почты, необходимо добавить два поля к пользовательской таблице (предполагающий, что это - таблица базы данных): дата, названная new_passwd_expire и строкой new_passwd_id.

Принятие у Вас есть адрес электронной почты пользователя, когда кто-то делает запрос на восстановление пароля, Вы обновляете пользовательскую таблицу следующим образом:

new_passwd_expire = now() + some number of days
new_passwd_id = some random string of characters (see below)

Затем, Вы посылаете электронное письмо пользователю в том адресе:

Дорогой такой-то

Кто-то запросил новый пароль на учетную запись пользователя <имя пользователя> в <Ваше имя веб-сайта>. Если Вы действительно делали этот запрос на восстановление пароля, перейдите по этой ссылке:

http://example.com/yourscript.lang? обновите = <new_password_id>

Если та ссылка не работает, можно перейти к http://example.com/yourscript.lang и ввести следующее в форму: <new_password_id>

Если Вы не сделали запрос на восстановление пароля, можно проигнорировать эту электронную почту.

Спасибо, yada yada

Теперь, кодирование yourscript.lang: для Этого сценария нужна форма. Если обновление var передало URL, форма просто просит имя пользователя и адрес электронной почты пользователя. Если обновление не передается, оно просит имя пользователя, адрес электронной почты и идентификационный код, отправленный в электронном письме. Вы также просите новый пароль (дважды, конечно).

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

По существу new_passwd_id поле является паролем, который только работает на странице сброса пароля.

Одно потенциальное улучшение: Вы могли удалить <имя пользователя> из электронной почты. "Кто-то имеет, делают запрос на восстановление пароля для учетной записи в этом адресе электронной почты...." Таким образом делая имя пользователя чем-то только пользователь знает, прерывается ли электронная почта. Я не начинался тот путь, потому что, если кто-то нападает на учетную запись, они уже знают имя пользователя. Этот добавленный мрак останавливает атаки "человек посередине" возможности в случае, если кто-то злонамеренный, оказывается, прерывает электронную почту.

Что касается Ваших вопросов:

генерация случайной строки: Это не должно быть чрезвычайно случайно. Любой генератор GUID или даже md5 (concat (соль, current_timestamp ())) достаточно, где соль - что-то на пользовательской записи как учетная запись метки времени, был создан. Это должно быть что-то, что пользователь не видит.

таймер: Да, Вам нужно это только для хранения базы данных нормальной. Не больше, чем неделя действительно необходима, но по крайней мере 2 дня, с тех пор как Вы никогда не знаете, сколько времени почтовая задержка могла бы продлиться.

IP-адрес: Так как электронная почта могла быть отложена из-за дней, IP-адрес только полезен для входа, не для проверки. Если Вы хотите зарегистрировать его, сделайте так, иначе Вам не нужен он.

Экран сброса: посмотрите выше.

Надеюсь, что покрывает его.Удачи.

8
ответ дан jmucchiello 24 November 2019 в 09:38
поделиться

1) Для генерации уникального идентификатора Вы могли использовать Безопасный Хеш-алгоритм. 2) таймер присоединяется? Вы имели в виду Истечение для сброса pwd ссылка? Да можно было установить Истечение 3), можно попросить еще некоторую информацию кроме отправленного по электронной почте проверять.. Как дата рождения или некоторые вопросы о безопасности 4) Вы могли также генерировать случайные символы и попросить вводить это также наряду с запросом.. для проверки запрос пароля не автоматизирован некоторым шпионским ПО или подобными вещами..

2
ответ дан Java Guy 24 November 2019 в 09:38
поделиться
Другие вопросы по тегам:

Похожие вопросы: