Внедрить лучшие практики восстановления пароля
Я хочу реализовать восстановление пароля в моем веб-приложении.
Я хотел бы избежать использования секретных вопросов.
Я мог бы просто отправить пароль по электронной почте, но я думаю, что это будет рискованно.
Возможно, я мог бы сгенерировать новый временный случайный пароль и отправить его по электронной почте, но я думаю, что это так же рискованно, как и вышеупомянутый пункт.
Могу ли я отправить URL-адрес по электронной почте, например, http://example.com/token=xxxx где xxxx - это случайный токен, связанный с пользователем. Поэтому, когда пользователь переходит на этот URL, он / она может сбросить пароль.
12 ответов
Прежде всего, не храните текстовую копию пароля пользователя или даже зашифрованную версию. Вы хотите хранить только хешированную копию пароля пользователя.
Что касается решений по восстановлению, я считаю, что ссылка восстановления для изменения пароля пользователя является лучшим решением в моем опыте. Вероятно, это будет немного удобнее для пользователя, хотя с точки зрения безопасности оно будет во многом таким же, как отправка нового случайного пароля, который будет изменен после следующего входа в систему. Я бы по-прежнему рекомендовал, чтобы срок действия URL-адреса восстановления истек через достаточно короткий промежуток времени, а также его можно было использовать только один раз.
Когда я был в ВВС, у нас было правило безопасности: при установке или сбросе паролей не отправляйте идентификатор пользователя и пароль в одном письме. Таким образом, если кто-то перехватывает электронные письма, отслеживающие пароли, он должен успешно перехватить ОБА электронные письма и иметь возможность подключить их, чтобы нарушить безопасность.
Я видел много сайтов, которые используют "перейдите по этому URL для сброса пароля". Может быть, я что-то упускаю - я не претендую на звание эксперта по безопасности - но я не понимаю, насколько это безопаснее, чем просто придумывать новый временный пароль и отправлять его. Если хакер перехватывает электронное письмо, почему он не может перейти по этой ссылке и увидеть новый пароль, как это мог бы сделать законный пользователь? Для меня это выглядит как дополнительная проблема для пользователя без повышения безопасности.
Кстати, поздравляю с НЕ использованием вопросов безопасности. Логика этого устройства ускользает от меня. На заре компьютерной безопасности мы говорили людям: "НЕ создавайте пароль, который представляет собой информацию о вас, которую хакер может обнаружить или угадать, например, название вашей средней школы или ваш любимый цвет. Хакер может чтобы найти название вашей средней школы, или даже если они не знают вас или ничего о вас не знают, если вы все еще живете рядом с тем местом, где вы ходили в школу, они могут получить его, попробовав местные школы, пока не доберутся до него. небольшое количество вероятных любимых цветов, чтобы хакер мог догадаться об этом. И т.д. Вместо этого пароль должен представлять собой бессмысленную комбинацию букв, цифр и знаков препинания ". Но теперь мы также говорим им: "Но! Если вам трудно вспомнить эту бессмысленную комбинацию букв, цифр и знаков препинания, не проблема! Возьмите некоторую информацию о себе, которую вы можете легко запомнить - например, название вашей средней школы". или ваш любимый цвет - и вы можете использовать его в качестве ответа на "секретный вопрос", то есть в качестве альтернативного пароля ".
Действительно, вопросы безопасности делают хакера еще проще, чем если бы вы просто выбрали неверный пароль для начала. По крайней мере, если вы просто использовали часть личной информации для своего пароля, хакер не обязательно будет знать, какую часть личной информации вы использовали. Вы использовали имя своей собаки? Ваша дата рождения? Ваш любимый вкус мороженого? Ему придется попробовать все из них. Но с вопросами безопасности мы сообщаем хакеру, какую именно личную информацию вы использовали в качестве пароля!
Вместо того чтобы задавать секретные вопросы, почему бы нам просто не сказать: "Если вы забыли свой пароль, он отображается в нижней части экрана. Если вы пытаетесь взломать чужой аккаунт, вам абсолютно запрещено прокручивая вниз." Это было бы только немного менее безопасно.
Чтобы вы не удивились, когда сайты спрашивают меня о городе, где я родился, или о производителе моей первой машины, я не даю точного ответа на этот вопрос. Я даю бессмысленный пароль.
Трудно сказать, что вам следует делать, так как практически любое решение этой проблемы ослабит безопасность. Если, возможно, вы не хотите расследовать отправку SMS, проверку обратного вызова, генераторы одноразовых паролей или другие подобные схемы, которые переносят восстановление пароля на другой носитель.
Однако, что вы не должны делать:
Отправьте пароль - ведь, как уже было сказано, у вас его нет.
Создайте новый временный пароль - это не только небезопасно, как отправка пароля, но также приводит к возможности атаки типа "отказ в обслуживании". Я могу зайти на сайт, притвориться вами, запросить новый пароль, а затем (если вы не проверили свою электронную почту) вы не можете войти в систему, не знаете почему и должны запросить новый пароль.,
Маркер - это, вероятно, путь. Получив его, вы получаете уведомление о запросе забытого пароля, но не предпринимаете никаких действий без вашего подтверждения. Вы также сделаете это одноразовым токеном с относительно коротким сроком действия, чтобы ограничить риск.
Конечно, многое зависит от приложения. Очевидно, что защита финансовой и другой конфиденциальной информации важнее, чем предотвращение взлома вашего аккаунта на mytwitteringfacetube.com, потому что хотя это неудобно, если кто-то хочет украсть чью-то личность на сайте социальной сети, он может просто открыть свой собственный аккаунт и маскироваться под украденное информация в любом случае.
Очевидно, что вы не можете отправить оригинальный пароль по электронной почте, потому что вы не храните его (верно?!). Отправка временного пароля (который должен быть изменен, потому что он работает только для одного входа в систему) и ссылка для сброса пароля эквивалентны с точки зрения безопасности.
Я не понимаю отношения к методу секретного вопроса. Это не значит, что я собираюсь сделать свой пароль "BlueHouse", а затем задать свой секретный вопрос "Какие две ваши любимые вещи?" и ответ "Блю и дома". Секретный вопрос не является волшебным ключом для получения действительного пароля. Обычно это способ получить новый пароль, отправленный на адрес электронной почты в файле. Я не знаю, как еще вы, ребята, делаете это, но, похоже, вы делаете одну из двух вещей.
1) Пользователь нажимает кнопку "Я забыл свой пароль", и новый пароль отправляется пользователю.
2) Пользователь нажимает кнопку "Я забыл свой пароль", а затем должен ответить на секретный вопрос, прежде чем получить новый пароль по электронной почте на адрес, указанный в файле.
Сдается мне, что вариант № 2 более безопасен.
Почему отправка токена более безопасна, чем отправка пароля? Если учетная запись электронной почты была взломана, она взломана. Неважно, есть ли ссылка для сброса пароля, токен или новый пароль. Не забывайте, что большинство сайтов не говорят "Новый пароль был отправлен на следующий адрес электронной почты, чтобы вы могли взломать". Хакеру нужно угадать адрес электронной почты, который нужно взломать.
Я согласен с Энди. Разве вопросы безопасности обычно не зависят от пароля? (мои) Это означает, что у них есть вопрос и ответ, и они не связаны с паролем. Похоже, что это используется для предотвращения ложных запросов на сброс пароля и на самом деле есть применение.
Представьте себе - кто-то может зайти в утилиту "забыл пароль" сайта и ввести миллион адресов электронной почты - или просто один человек, которого он хочет раздражать. Если пароль будет сброшен в этот момент, люди, принадлежащие к этим адресам электронной почты, должны будут в своем электронном письме заметить сброс пароля и войти в систему с паролем сброса при следующем посещении. С вопросом безопасности это не так просто для кого-то сделать.
Я вижу, что Amazon отправляет ссылку на указанный адрес электронной почты. Они также требуют от вас ввести капчу, чтобы предотвратить атаки DOS. Поскольку это ссылка, я думаю, это означает, что они не сбросили пароль сразу, и он будет сброшен, как только пользователь щелкнет ссылку. При описанном выше сценарии пользователь просто увидит электронное письмо и заметит, что "нет, я этого не делал" и займется своим делом, не меняя пароль без необходимости. Секретный вопрос мог помешать попытке с самого начала и законному пользователю получить письмо в первую очередь.
Вот технический документ: http://appsecnotes.blogspot.com/2010/09/latest-forgot-password-best-practices.html
Этот на самом деле рекомендует секретные вопросы в качестве основной части процесса аутентификации. А отправка кода аутентификации по электронной почте и запрос его - это просто дополнительный слой, который вы можете по желанию включить.
Это действительно сводится к тому, сколько безопасности вы хотите иметь. Одним из крайностей является процесс сброса пароля, который включает в себя установление контакта и подтверждение того, что вы являетесь тем, кем себя называете, например, с помощью id, потому что ваш почтовый ящик также может быть взломан. На самом деле, поскольку люди, как правило, используют один и тот же пароль везде, это очень вероятно. С другой стороны, существует стандартный подход, который заключается в отправке электронного письма со случайным новым паролем.
"Секретные" вопросы и ответы - это просто еще одна форма имени пользователя и пароля с фатальной ошибкой, которую обычно невероятно легко угадать, настолько хорошей, что вы не хотите их использовать.
Что касается вашего токена, я не думаю, что он имеет большое значение в общей безопасности. Независимо от того, отправляете ли вы токен, который позволяет пользователю сменить пароль, или сразу отправляете случайный пароль, это не имеет большого значения.
Просто убедитесь, что токен можно использовать только один раз и желательно только в течение ограниченного промежутка времени, например, +24 часа после запроса.
И, как указывалось в предыдущих ответах, НИКОГДА не храните простые пароли. Хэш их. Желательно добавить соль.
Вот как я решил это:
я добавил retrieve_token а также retrieve_expiration поля для моей таблицы пользователей.
Пользователь запрашивает сброс пароля, предоставив свой адрес электронной почты и заполнив код безопасности. Случайное хэшированное значение генерируется для их retrieve_token поле - т.е. md5($user_id.time()), в то время как retrieve_expiration будет установлено время, которое истекает в течение следующих 45 минут. Электронная почта отправляется пользователю со ссылкой:
https://example.com/reset-password?retrieve_token=912ec803b2ce49e4a541068d495ab570
SSL должен быть обязательным, когда требуется аутентификация. Вы также можете добавить таблицу для регистрации запросов на сброс, которая хранит электронную почту и IP-адрес. Это помогает отследить возможные грубые атаки, и вы можете при необходимости заблокировать IP-адрес злоумышленника.
Вы могли бы реализовать секретный вопрос для запроса сброса пароля, но я чувствую, что капч было бы достаточно, чтобы отговорить кого-либо повторять запрос несколько раз.
@Jay. Причина, по которой вы переходите по URL-адресу для сброса пароля вместо того, чтобы просто отправить кому-то новый временный пароль, заключается не только в безопасности. Без чего-то вроде URL с токеном человек может сбросить пароль другого человека. Нет необходимости получать доступ к электронной почте. Если у кого-то есть кость, которую он может выбрать у кого-то, он может просто инициировать сброс нового пароля. Тогда бедная цель должна войти и изменить пароль снова и снова.
При отправке токена пароль пользователя не изменяется до тех пор, пока он не войдет с ним и не подтвердит его. Спам сбрасываемых писем можно игнорировать. Токены так же легко (если не проще) генерировать как новый пароль с помощью GUID, для разработчика это не создает особых проблем.
Кроме того, поскольку GUID является уникальным (сгенерированный пароль может не быть), токен может быть привязан к имени пользователя. Если в URL указано неверное имя пользователя, токен можно отменить (т. Е. Когда другой человек инициирует его и кто-то его перехватит… при условии, что имя пользователя не совпадает с адресом электронной почты).
@Jay. Правильное использование вопросов безопасности - инициировать электронную почту для сброса пароля, а не для фактического сброса пароля. Без такого механизма, как секретный вопрос, можно инициировать сброс пароля. Несмотря на то, что, казалось бы, правдоподобно, отправка сообщения об удалении может быть отправлена на электронное письмо, которое может больше не принадлежать первоначальному владельцу. Это не редкость. Например, когда сотрудники покидают компанию, часто эти письма пересылаются другому сотруднику. Секретный вопрос добавляет низкий уровень обфускации к этому сценарию. Это также устраняет проблемы, при которых один человек продолжает инициировать сброс пароля с неверной учетной записи, что приводит к непреднамеренному рассылке нежелательной почты. Секретный вопрос на самом деле не предназначен для того, чтобы быть по-настоящему безопасным, он просто предназначен для уменьшения таких сценариев. Любой, кто использует секретный вопрос для сброса пароля, делает это неправильно.
Вот пример того, как кто-то сделал это с Node.js, в основном генерирует случайный токен, время истечения, отправляет ссылку с прикрепленным токеном, имеет reset/:token маршрут, который гарантирует, что пользователь существует с этим токеном (срок действия которого также не истек) и, если это так, перенаправляет на страницу сброса пароля.
http://sahatyalkabov.com/how-to-implement-password-reset-in-nodejs/
По поводу секретного вопроса / ответа. Как пользователь веб-сайтов, я лично ими не пользуюсь (я ввожу в них мусор). Но они, конечно, не бесполезны или бессмысленны, как некоторые говорят здесь.
Рассмотрим следующую ситуацию: пользователь вашего сайта покинул свой стол, чтобы пойти на обед, и не заблокировал свою рабочую станцию. Теперь злоумышленник может зайти на страницу для восстановления / сброса пароля и ввести имя пользователя. Затем система отправит восстановленный / сброшенный пароль по электронной почте, не запрашивая ответ безопасности.