Какой самый лучший метод “забыл свой пароль”?[дубликат]

Question

Возможный Дубликат:
Забыли пароль:каков наилучший метод реализации функции "Забыли пароль"?

Я программирую веб-сайт сообщества.

Я хочу создать функцию "забыл свой пароль".

Просматривая разные сайты, я обнаружил, что они используют один из три варианта:

1. отправьте пользователю электронное письмо со ссылкой на уникальный скрытый URL это позволяет ему сменить свой пароль (Gmail и Amazon).

2. отправьте пользователю электронное письмо с новый, случайно сгенерированный пароль (Wordpress)

3. отправить пользователю его текущий пароль (www.teach12.com)

Вариант №3 кажется наиболее удобным для пользователя, но поскольку я сохраняю пароли в виде хэша MD5, я не вижу, как вариант # 3 будет доступен для меня, поскольку MD5 необратим.Это также, по -видимому, неуверенный в себе опция, поскольку это означает, что веб-сайт должен где-то сохранять пароль в виде открытого текста, и, по крайней мере, пароль в виде открытого текста отправляется пользователю по небезопасной электронной почте.Или я здесь что-то упускаю?

Итак, если я не могу выполнить вариант № 1, вариант №2 кажется, это тот самый самый простой в программировании поскольку мне просто нужно изменить пароль пользователя и отправить его ему.Хотя это несколько неуверенный в себе поскольку у вас должен быть действующий пароль, передаваемый по небезопасной электронной почте.Однако это также может быть использовано злоумышленниками для приставать к пользователям набирая случайные электронные письма и постоянно меняя пароли различных пользователей.

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

Какой опыт у вас был в использовании / программировании этих различных опций?Есть ли какие-то варианты, которые я пропустил?

Answer 1

4) Пополните их банковский счет двумя случайными суммами и попросите их ввести их.
5) Улитка отправит им по почте какой-нибудь новый пароль и попросит ввести его.
6) Попросите их написать текст или позвонить по какому-нибудь номеру и ввести некоторое значение для телефонного номера с мобильного телефона, который они зарегистрировали в файле.
7) Полностью избавьтесь от проблемы управления паролями, передав ее на аутсорсинг поставщикам OpenID, таким как Stack Overflow, Facebook, движки блогов и другие начинают это делать.

Помимо них, используйте вариант № 1 или № 2 с добавленной функцией, срок действия которых истекает через час.

Answer 2

Я шокирован повышением голосов по ответам, описывающим # 1 и # 2 как эквивалентные.Это совсем не так.Отправка пользователю краткосрочной ссылки для смены пароля является наиболее удобным, наиболее часто используемым и наиболее безопасным подходом, который не требует внешнего взаимодействия (почта, текстовые сообщения и т.д.).Несколько причин:

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

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

Answer 3

Обратите внимание, что опция # 2 также требует, чтобы вы отслеживали старый пароль и срок действия нового случайного пароля истек, если он не был использован в течение, скажем, 24 часов.

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

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

Answer 4

Варианты 1 и 2 столь же небезопасны, как и друг друга.

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

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

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

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

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

Answer 5

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

Фактически, учитывая распространенность фишинговых атак, можно утверждать, что поощрение использования варианта 1 с длинными URL-адресами может сделать людей менее настороженными по поводу нажатия на длинные таинственные URL-адреса.

Answer 6

Прочтите Первая десятка OWASP чтобы убедиться, что ваш метод соответствует требованиям.

Здесь это прямая ссылка.

Answer 7

Просто краткое замечание о чем-то, не относящемся конкретно к вашему вопросу.Вы упомянули, что использовали MD5 для хэширования сохраненных паролей.Независимо от того, выберете ли вы варианты 1 или 2 (3 по понятным причинам будет наименее безопасным), MD5 - это взломанный алгоритм хеширования, который на самом деле может упростить хакерам получение доступа к учетным записям, защищенным хешированием MD5.

Вы можете прочитать больше об уязвимости it по следующему URL:en.wikipedia.org/wiki/MD5

Лучшим решением для хеширования было бы что-то вроде SHA, которое по-прежнему является стабильным и безопасным алгоритмом хеширования.В сочетании с вариантом № 1 или № 2 у вас должна быть достаточно безопасная система для защиты паролей ваших пользователей, недоступная всем, кроме самых решительных хакеров.

Answer 8

Вариант № 1, вероятно, самый лучший.# 3 небезопасен (и я также предлагаю использовать что-то более сильное, чем MD5, например SHA1).Вариант № 2 не подходит, потому что он позволяет любому случайному человеку заблокировать вас в вашей учетной записи до тех пор, пока вы не проверите свою электронную почту, если только вы не используете секретный вопрос.А секретные вопросы часто легче взломать, чем пароли.

Answer 9

Вариант № 1 имеет несколько основных преимуществ по сравнению с вариантом №2.Если случайный пользователь введет мой адрес электронной почты в поле "Я забыл свой пароль", то мой пароль не будет сброшен.Кроме того, это немного более безопасно, поскольку в вашем почтовом ящике gmail нет постоянной записи пароля сайта, который хранится вечно.

Критическим упущением здесь является то, что ссылка, которую вы предоставляете в # 1 должно работать только для одного сброса пароля и иметь ограничение по времени

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

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

Answer 10

Вариант 4:Потребовать от пользователя сбросить пароль, введя имя своей учетной записи И адрес электронной почты.До тех пор, пока вы не раскрываете настоящие имена или адреса электронной почты на сайте (зачем вам это в наше время?) это достаточно безопасный метод, защищенный от несанкционированного доступа.Отправьте ссылку на страницу сброса, а не сам пароль.

Вариант 5:Использование OpenID и передайте ответственность третьей стороне, чтобы она позаботилась об этом.

Хотя, честно говоря, это требует намного больше усилий, чем требуется большинству сайтов.Мне, например, НРАВИТСЯ получать текстовые пароли по электронной почте, потому что я храню их в папке "регистрации" в своем почтовом ящике.Таким образом, я могу искать пароли для сайтов, когда я их забываю (что случается часто!).Если кто-то читает мою электронную почту, у меня есть причины для беспокойства посерьезнее, чем у людей, использующих мой аккаунт в Twitter (если бы он у меня был).Конечно, у банков и корпораций более строгие требования, но вы не указали, что представляет собой ваш сайт.Это ключ к лучшему ответу.

Answer 11

Я согласен с вашими комментариями о том, что вариант № 3 небезопасен.

Что касается программирования # 1 или # 2, вариант # 2 проще в программировании, но # 1 не намного сложнее, и оба, вероятно, примерно так же безопасны, как и друг друга.

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

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

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

Очевидно, что чем больше этого вы делаете, тем больше это требует работы по программированию.

Самый простой метод - это:

1. Укажите ссылку "напомните мне мое имя пользователя" (введите адрес электронной почты).Не сообщайте пользователю, было ли отправлено электронное письмо или нет, потому что люди могут использовать это, чтобы узнать, принадлежит ли адрес электронной почты участнику.Всегда советуйте пользователю проверить свой почтовый ящик на наличие электронного напоминания, но отправляйте его только в том случае, если кто-то является участником;и
2. Для отправки нового одноразового пароля требуются имя пользователя и адрес электронной почты.Этот пароль должен действовать всего час или около того.Когда пользователь использует его, он должен быть вынужден немедленно сменить свой пароль.

Answer 12

Подойдет любой вариант 1 или 2.Как вы сказали, вариант 3 небезопасен, так как вам нужно будет сохранить пароль в виде открытого текста.Вероятно, вы могли бы пофантазировать и использовать обратимый алгоритм шифрования для хранения / извлечения пароля, но при наличии у вас лучших альтернатив нет причин идти по этому пути.

Answer 13

Существует дополнительная опция, которую вы можете использовать в сочетании с любым из упомянутых вами вариантов:

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

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

Answer 14

Если вы их хэшируете, вариант 3 недоступен, и если вы их не хэшируете, позор вам.:)

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

Answer 15

Вы могли бы смешать # 1 и # 2, используя преимущества обоих:

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

Эта страница может быть SSL, и срок действия пароля может истечь через 12-24 часа.

Answer 16

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

1. Пользователь вводит имя пользователя и адрес электронной почты
2. Электронное письмо, отправленное со ссылкой, содержащей URL и параметр guid, которая была сохранена в базе данных с 48-часовым истечением
3. Пользователь подтверждает, что пароль должен быть сброшен
4. Новый пароль высылается пользователю по электронной почте
5. Вход с новым паролем отображает сообщение или перенаправляет на страницу смены пароля.

Answer 17

Проинструктируйте пользователя лично прийти в ваши офисы и подтвердить свою личность с помощью удостоверения личности или паспорта.

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