Ограниченные по времени или одноразовые маркеры сброса пароля?

Question

пользователи забывают пароли, и (почти) все места членства нужен способ, чтобы помочь пользователям получить обратно в

Я хотел бы реализовать общий сценарий:.

1. Пользователь ударяется сайт, пытается войти в систему в, не может, и понимает, что они забыли пароль - дерьмо!
2. Пользователь вводит адрес электронной почты и щелкает «забыли пароль»
3. Пользователь получает электронное письмо со ссылкой для сброса пароля

Вот как я планирую осуществить это (C#/ASP.NET MVC):

1. Когда пользователь вводит электронную почту и удаляет «забытый пароль», мой сайт будет генерировать GUID, хранить его на объекте участника в БД (member.ResetToken) и отправлять им ссылку с этим GUID в URL-адресе что они могут использовать эту ссылку только один раз)
2. Пользователь нажимает на ссылку, и мой сайт просматривает свою учетную запись на основе этого member.ResetToken с URL-адреса. Если их учетная запись найдена, покажите им форму сброса пароля, и когда они завершат сброс, она очищает member.ResetToken от их учетной записи.

Вот мой вопрос: сохраните его так (в котором они могут сбросить свой пароль с помощью этой ссылки в любое время, сейчас или в будущем) или добавить временную метку, чтобы ограничить, как долго они должны сбросить свой пароль?

С точки зрения UX возможность сброса пароля каждый раз, когда вы готовы, отлично, но я хочу убедиться, что я не буду забывать о некоторых проблемах безопасности, которые могут возникнуть.

Answer 1

Пользователи также забывают сбросить пароли (все происходит). Будучи параноиком относительно паролей, я бы предложил ограничить продолжительность жизни ссылки до 24 часов. Этого должно быть более чем достаточно. Он не решает проблему вредоносного перехвата, но лучше, чем ничего.

Answer 2

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

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

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

Вот этот процесс должен использовать.

1. Сформировать запрос на сброс пароля, который вы смотрите вверх, используя код GUID, и вы, вероятно, можете также обеспечить это путем хеширования, что значение с некоторыми частными данными и попутно, что в URL, а также, чтобы избежать быстрого нападения.Вы также можете заблокировать этот запрос, сделав его действительным только в течение определенного периода времени.
2. После того, как кто-то следует этой ссылке с действительным токеном и любыми другими параметрами, которые вы указали, они могут затем изменить пароль, с которого теперь вы можете безопасно изменить пароль пользователей.
3. Отметьте запрос пароля как выполненный или удалите его. Вы также можете отслеживать информацию, такую ​​как IP-адрес или что-то подобное, если вы действительно обеспокоены тем, кто изменил пароль, если вы действительно обеспокоены этим.
4. Отправьте пользователю электронное письмо с подтверждением того, что они изменили свой пароль.

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

Answer 3

Я хотел бы сделать следующие предложения:

1. Требовать некоторую часть информации до того, как пользователь может нажать на кнопку забыл пароль. Например, укажите адрес электронной почты и дату рождения.

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

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

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

3. Не используйте GUID. Они не являются криптографически случайными и допустимы. Я предлагаю вам использовать криптографический генератор случайных чисел и перевести его в base64.

Answer 4

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

Давайте зададим обратный вопрос: Почему маркер остается действительным бесконечно?

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

Главное, что вы должны сохранить в своей базе хэш.Кто-то, у кого есть доступ к базе данных (SQL-injection), в противном случае мог бы потребовать сброс пароля для любого адреса электронной почты, который ему нравится, и потому что он может видеть новый токен, он может использовать его для установки своего собственного пароля.

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

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

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