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

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

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

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

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

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

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

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

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

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

Вариант 4. Требовать от пользователя сброса пароля, введя имя своей учетной записи И адрес электронной почты. Пока вы не раскрываете настоящие имена или адреса электронной почты на сайте (ПОЧЕМУ бы вы в наши дни?), Это достаточно безопасный и защищенный от взлома метод. Отправьте ссылку на страницу сброса, а не сам пароль.

Вариант 5: Используйте OpenID и передайте ответственность сторонней организации, которая будет беспокоиться об этом.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Здесь - прямая ссылка.

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

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

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

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

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

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

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

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

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

Options 1 and 2 as insecure as each other.

There. I said it. If the user's email account has been breached, there's no reasonable secure way to do things unless you collect more private data like their address, mother's maiden name - all of which can be guessed.

The best (albeit most annoying) version I have seen is where you need to remember a secret question and a secret answer. It means the user has to remember which question they asked, which, of course, can always be forgotten too!

If they forget the question and you're a "real" company, there's always the option of sending the user a token through the post, with instructions on how to reset all their security... It's very unlikely that a hacker will have access to their real life mail.

A skew on that would be to collect a telephone number when the user created the account. If that existed and they couldn't remember any of their details, you could set up some sort of automated calling system that told them how to reset their details.

And one thing to mention about #2: Don't let the process overwrite the current account password. If that happened anybody could say they forgot any account's password, triggering lots of unwanted password changes.

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

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

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

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

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

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

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

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

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

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

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