Рассмотрите мой дизайн: средство сброса Пароля для веб-сайта

Q1. ИМХО, здесь есть недостаток. Почему вы просите пользователя ввести новый пароль? Я бы лучше сгенерировал новый случайный пароль и отправил его пользователю. Получив его, пользователь может войти в систему, используя этот случайно сгенерированный пароль, а затем изменить его в своем профиле.

Я предлагаю следующую систему, используемую на большинстве сайтов:

1. Пользователь вводит адрес почты в форму "Сброс пароля".
2. Почта проверяется (т.е. есть ли пользователь с таким адресом в базе данных?)
3. Новый пароль генерируется случайным образом и отправляется по почте, затем соленый/хэшированный и сохраняется в базе данных.
4. Пользователь входит в систему.

Это просто и привычно, поэтому пользователи не потеряются.

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

• Установки коэффициента сброса пароля. После отправки формы IP-адрес и отправленные данные запоминаются: теперь в течение нескольких минут никто с того же IP-адреса больше не сможет сбросить пароль.
• Новый пароль не заменяет старый: вместо него можно использовать оба. Представьте, что кто-то сбрасывает пароль другого пользователя. Этот пользователь все еще должен иметь возможность войти в систему со старым паролем, если он/она не прочитал/а или не получил/а письмо с новым паролем.

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

Во-первых, я бы предложил вам относиться к сбросу пароля как к безопасной бизнес-транзакции. SSL включен, и один запрос не зависит от других запросов для той же учетной записи. Сгенерируйте случайный, невоспроизводимый ID транзакции и свяжите его с ЭТИМ ОДНИМ запросом на сброс пароля. Затем в электронное письмо, которое вы им отправите, вставьте идентификатор транзакции с URL:

http://www.yoursite.com/passwordreset/?id=e3dXY81fr98c6v1

Эта так называемая транзакция сброса пароля должна быть связана с учетной записью и иметь метаданные, связанные со сбросом пароля, такие как дата запроса и дата истечения срока действия. Сама учетная запись должна знать только о том, что с ней связан(ы) ожидающий(ие) сброс(ы) пароля.

Кроме того, когда пользователь просит сбросить пароль, забудьте о секретном вопросе - гораздо безопаснее послать ему электронное письмо, которое должно быть у вас ВСЕГДА в файле. (Если у вас его нет, то начните его собирать!) - еще лучше использовать адрес электронной почты в качестве имени пользователя.

Когда пользователь вводит новый пароль с URL-адреса идентификатора транзакции, вы доверяете, что это именно тот человек, о котором вы думаете. Чтобы убедиться в этом, вы можете просто попросить пользователя повторно ввести свое имя пользователя (что вы уже подтвердили).

Оптимально:

1. Войти в систему через OpenID. Меньше сложностей с кодированием, меньше кликов, меньше набора текста, меньше потраченного времени.
2. Готово. Вопрос снят. Больше не нужно беспокоиться, кто-то другой уже решил эту проблему.

Существует миллиард сайтов, использующих миллиард схем аутентификации, и в 99,999% случаев в этом нет необходимости. Почему я как пользователь должен доверять вам как разработчику в том, что вы не сохраните мой пароль в открытом виде, не передадите его и не взломаете сами? Мало кто использует разные пароли для каждого сайта...

Если это невозможно, то сделайте это как можно проще:

1. Я нажимаю на ссылку "Забыли пароль?". Это автоматически отправляет письмо, если я уже ввел e-mail (например, после неудачной попытки входа). Если я его не вводил, просто скройте поле для ввода пароля и скажите мне сделать это. Не перезагружайте и не перенаправляйте меня на другую страницу.
2. Я получаю ссылку с каким-то ключом (например, https://site.com/account/reset?key=a890ea8219175f890b7c123ee74a22). Какой-то уникальный хэш, который привязан к моей учетной записи и истекает через столько-то и столько-то часов. Используйте SSL, если это вообще возможно.
3. Я нажимаю на ссылку, и вы получаете данные моего аккаунта по ключу, убеждаясь, что он действителен и не истек. Я дважды ввожу свой новый пароль. Я уже знаю, какой у меня адрес электронной почты, а вы уже знаете, какой у меня адрес электронной почты, и любой потенциальный хакер также знает, какой у меня e-mail, так что не просите меня вводить его. То, что ссылка будет действовать целый день, - это перебор. Выдерживайте ее в течение часа или меньше.
4. Я ненавижу вопрос о безопасности. Не задавайте мне его. По сути, это просто второй пароль, который намеренно сделан менее надежным, чтобы вы всегда его помнили. У меня нет МЧП, я не знаю девичью фамилию своей матери и т.д. Прекратите это. Я знаю, что это сделано для того, чтобы оградить вас от незнакомцев, которые могли взломать вашу электронную почту, но если вы не PayPal, я думаю, что это просто излишняя инженерия.
5. Когда вы убедитесь, что пароли совпадают и они приемлемы, обновите базу данных (храните только соленый хэш моего пароля, а не сам пароль!) и немедленно введите меня в систему. Не перенаправляйте меня на страницу входа в систему, где я должен повторно ввести информацию, которую я уже несколько раз вам сообщал (и это при том, что вы уже знаете, что это я, и доверяете мне настолько, что я сам сменил пароль). Это так раздражает. Пользователи нетерпеливы.

Мне также не нравятся случайно сгенерированные пароли по следующим причинам:

1. Обычно я просто вставляю пароль из почты. Копирование пароля - это то, что вы никогда не хотите, чтобы пользователь делал.
2. Мне приходится менять пароль вручную, что означает возиться с панелью управления пользователя, настройками учетной записи или чем-то еще. Я становлюсь нетерпеливым! Вы можете сделать так, чтобы "смена пароля" происходила в тот момент, когда я вхожу в систему с одноразовым паролем, но это означает усложнение кода. Теперь вам нужно добавить флаг для этого, добавить еще один редирект, обработать случай, когда пользователь задерживается при вводе нового пароля, и т. д.
3. Поскольку я всего лишь человек, а у людей бывает СДВГ, я обычно забываю сделать все вышеперечисленное и в итоге получаю дерьмовый пароль, который мне приходится искать и копировать из электронной почты, когда мне нужно войти в систему в следующий раз. Моя вина, но я все равно буду винить в этом ваш сайт. ;-)

Решение со случайной генерацией пароля также подразумевает менталитет, что вы всегда будете использовать решение на основе пароля, в то время как аутентификация на основе ссылок кажется будущим (OpenID и т.д.) с точки зрения удобства и безопасности (я не хочу, чтобы сотня маленьких сайтов знала мои данные для входа!).

Обновление в ответ на комментарий:

Почему хэша должно быть достаточно: если хакер может угадать все 128+ бит (скажем) сгенерированного вами хэша (и в течение часа), то почему бы ему или ей не быть в состоянии угадать и e-mail? Я знаю, что "кажется" гораздо более безопасным попросить указать e-mail и/или задать вопрос безопасности, но если подумать, то e-mail обычно очень предсказуем и однороден, с низким уровнем энтропии. Я сомневаюсь, что в них можно рассчитывать на то, что они содержат более 50 бит информации. (Скорее всего, гораздо меньше.) Готов поспорить, что я скорее угадаю ваш e-mail, чем 50-битное случайное целое число. Но если это действительно беспокоит, все, что вам нужно сделать, это добавить больше битов в хэш. 256 бит или около того должно хватить для режима overkill - SHA256(соль, email, старый хэш pw, метка времени, возможно, несколько байт с /dev/urandom) или что-то подобное... Если хакер сможет предсказать это, вы мало что сможете сделать. Очевидно, что он контролирует Матрицу и может просто спроецировать свой разум на магнитные пластины внутри ваших жестких дисков, если захочет.

Все еще за OpenID: любой новый сайт, который я посещаю и который требует, чтобы я создал пользователя, должен быть очень убедительным в том, почему они хотят знать мой (бросовый) пароль и что они предлагают мне в плане безопасности, чего не делает OpenID или Google/Facebook/etc. - или почему они не доверяют Google/Facebook/etc. Никто (из тех, кого я знаю) не запоминает 30 разных паролей. Обычно люди используют их повторно, Так что если бы эти сторонние создатели сайтов захотели, им было бы очень легко обмануть своих пользователей. Если бы я зарегистрировался на вашем сайте со своей обычной информацией, вы могли бы при желании немедленно завладеть моими аккаунтами Last.FM и Reddit, а также, вероятно, дюжиной сайтов, которыми я пользовался пару раз и забыл о них. На самом деле, в наше время я как бы ожидаю, что сайты либо невежественны, либо имеют злой умысел, если хотят получить данные, которые им совершенно не нужны, поэтому я и называю это паролем на выброс - при каждой регистрации я как будто говорю: "Вот, возьмите мой аккаунт Reddit, это тот же Л/П, который я буду использовать для вашего сайта (иначе я бы просто забыл). Все в порядке, я не особенно привязан к нему". Конечно, Google мог бы фактически взять под контроль все мое онлайновое "я", если бы захотел, но пока я буду доверять Google больше, чем вам (без обид!).