Внедрение лучшей практики восстановления пароля

Я хочу реализовать восстановление пароля в своем веб-приложении.

Я бы хотел избежать секретных вопросов.

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

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

Могу ли я отправить URL-адрес, например, по электронной почте http://example.com/token=xxxx где xxxx - случайный токен, связанный с пользователем. Поэтому, когда пользователь переходит к этому URL, он может reset ввести пароль.

Ответ 1

Прежде всего, не хранить текстовую копию пользовательского пароля или даже зашифрованную версию. Вы хотите только сохранить хешированную копию пароля пользователя.

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

Ответ 2

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

Я видел много сайтов, которые используют "перейдите по этому URL-адресу к reset вашему паролю". Может быть, я что-то пропустил - я не утверждаю, что я эксперт по безопасности, но я не понимаю, как это безопаснее, чем просто изобретать новый временный пароль и отправлять его. Если хакер перехватывает электронное письмо, почему он не может перейти к этой ссылке и не видит новый пароль, а также законный пользователь? Мне кажется, что это лишний хлопот для пользователя без усиления безопасности.

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

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

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

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

</напыщенная >

Ответ 3

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

Однако, что вы не должны делать:

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

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

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

Ответ 4

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

Ответ 5

Я не разбираюсь в отношении секретного вопроса. Не похоже, что я сделаю свой пароль "BlueHouse", а затем сделаю свой вопрос безопасности "Каковы ваши две любимые вещи?" и ответ "Синий и дом". Вопрос безопасности не является волшебным ключом для получения фактического пароля. Обычно это способ получить новый пароль, отправленный на адрес электронной почты в файле. Я не знаю, как еще вы это делаете, но похоже, что вы делаете одну из двух вещей.

1) Пользователь нажимает кнопку "Я забыл свой пароль", и новый пароль отправляется пользователю.

2) Пользователь нажимает кнопку "Я забыл свой пароль", а затем должен ответить на вопрос безопасности, прежде чем получать новый пароль по электронной почте по адресу в файле.

Мне кажется, что опция номер 2 более безопасна.

Почему отправка маркера более безопасна, чем отправка пароля? Если учетная запись электронной почты была взломана, она была взломана. Не имеет значения, существует ли ссылка на reset пароль, токен или новый пароль. Не забывайте, что большинство сайтов не говорят "Новый пароль был отправлен на следующий адрес электронной почты для взлома". Хакеру нужно угадать адрес электронной почты, который нужно взломать.

Ответ 6

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

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

Я вижу, что Amazon отправляет ссылку на данное письмо. Они также требуют, чтобы вы вводили капчу, чтобы предотвратить атаки DOS. Поскольку это ссылка, я полагаю, что это означает, что они не reset пароль немедленно, и это будет reset, как только пользователь нажмет на ссылку. В приведенном выше сценарии пользователь просто увидит сообщение электронной почты и заметит, что "нет, я этого не делал", и продолжаю заниматься своим делом, не требуя лишнего изменения пароля. Защитный вопрос, возможно, помешал попытке в начале, а законному пользователю было получить электронное письмо в первую очередь.

Вот документ на нем: http://appsecnotes.blogspot.com/2010/09/latest-forgot-password-best-practices.html

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

Ответ 7

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

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

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

Просто убедитесь, что токен используется только один раз и предпочтительно только в ограниченный промежуток времени, например. + 24h после запроса.

И, как указывалось в предыдущих ответах, НИКОГДА не сохраняйте простые пароли. Хеши их. Предпочтительно добавьте salt.

Ответ 8

Вот как я его разрешил:

Я добавил поля retrieve_token и retrieve_expiration в таблицу 'users'.

Пользователь запрашивает пароль reset, предоставляя свою электронную почту и заполняя captcha. Для своего поля retrieve_token генерируется случайное хешированное значение, т.е. md5($user_id.time()), а retrieve_expiration будет установлено значение datetime, срок действия которого истекает через следующие 45 минут. Электронная почта отправляется пользователю со ссылкой:

https://example.com/reset-password?retrieve_token=912ec803b2ce49e4a541068d495ab570

SSL должен быть обязательным, когда требуется аутентификация. Вы также можете добавить таблицу для регистрации reset запросов, которые хранят электронную почту и IP-адрес. Это помогает отследить возможные грубые атаки, и вы можете заблокировать IP-адрес злоумышленника, если это необходимо.

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

Ответ 9

@Jay. Причина, почему вы переходите к URL-адресу reset вашего пароля вместо того, чтобы просто отправлять кому-то новый временный пароль, - это больше, чем просто безопасность. Без чего-то вроде URL-адреса с токеном, человек мог бы reset пароль других лиц. Нет необходимости получать доступ к электронной почте. Если у кого-то есть кость, чтобы выбрать кого-то, они могли бы просто начать новый пароль reset. Затем бедной цели необходимо войти в систему и изменить пароль снова и снова.

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

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

Ответ 10

@Jay. Правильное использование вопросов безопасности заключается в том, чтобы инициировать пароль reset, а не для фактического сброса пароля. Без механизма, такого как вопрос безопасности, можно было бы инициировать пароль reset. Хотя, похоже, beign, отправка электронной почты reset может быть отправлена по электронной почте, которая больше не может принадлежать первоначальному владельцу. Это не редкость. Например, когда сотрудники покидают компанию, часто эти письма отправляются другому сотруднику. Защитный вопрос добавляет низкий уровень увлечения к этому сценарию. Это также уменьшает проблемы, когда один человек продолжает вводить пароль reset в неправильную учетную запись, что приводит к тому, что некоторые бедные sod получают непреднамеренно spammed. Вопрос безопасности действительно не предназначен для того, чтобы быть действительно безопасным, они предназначены только для сокращения таких сценариев. Любой, кто использует секретный вопрос на самом деле reset, делает неправильный пароль.

Ответ 11

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

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

Ответ 12

Здесь пример того, как кто-то сделал это с помощью Node.js, в основном генерирует случайный токен, время истечения срока действия, отправляет ссылку с прикрепленным токеном, имеет маршрут reset/:token, который гарантирует, что пользователь существует с этим токен (который также не истек) и, если это так, перенаправить на страницу пароля reset.

http://sahatyalkabov.com/how-to-implement-password-reset-in-nodejs/