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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

читать OWASP top ten чтобы убедиться, что ваш метод является совместимым.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

самый простой способ-это:

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

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

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

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

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

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

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

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

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

эта страница может быть SSL, и пароль может истечь через 12-24 часа.

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

1. пользователь вводит имя пользователя и адрес электронной почты
2. электронная почта отправляется со ссылкой, содержащей url и GUID param, который был сохранен в БД с 48-часовым сроком действия
3. пользователь подтверждает пароль для сброса
4. новый пароль отправляется по электронной почте пользователю
5. войти с новым паролем отображает сообщение или перенаправляет для изменения пароля страница.

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

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