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

Question

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

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

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

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

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

Answer 1

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

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

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

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

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

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

Answer 2

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

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

Answer 3

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

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

• Отправьте пароль - ведь, как уже было сказано, у вас его нет.

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

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

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

Answer 4

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

Answer 5

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

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

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

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

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

Answer 6

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

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

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

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

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

Answer 7

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

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

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

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

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

Answer 8

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

Я добавил поля retrieve_token и retrieve_expiration в свою таблицу пользователей.

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

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

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

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

Answer 9

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

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

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

Answer 10

@ Джей. Правильное использование вопросов безопасности - инициировать электронную почту для сброса пароля, а не для фактического сброса пароля. Без такого механизма, как секретный вопрос, можно инициировать сброс пароля. Несмотря на то, что, казалось бы, правдоподобно, отправка сообщения о сбросе может быть отправлена ​​на электронное письмо, которое может больше не принадлежать первоначальному владельцу. Это не редкость. Например, когда сотрудники покидают компанию, часто эти письма пересылаются другому сотруднику. Секретный вопрос добавляет низкий уровень обфускации к этому сценарию. Это также устраняет проблемы, при которых один человек продолжает инициировать сброс пароля с неверной учетной записи, что приводит к непреднамеренному спаму некоторых плохих пользователей. Секретный вопрос на самом деле не предназначен для того, чтобы быть по-настоящему безопасным, он просто предназначен для уменьшения таких сценариев. Любой, кто использует секретный вопрос для сброса пароля, делает это неправильно.