Подтвердить что ты не робот

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

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

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

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

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

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

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

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

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

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

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

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

4b9b3361

Ответ 1

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

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

Ответ 2

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

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

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

Ответ 3

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

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

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

Ответ 4

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

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

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

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

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

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

Ответ 5

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

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

Ответ 7

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

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

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

Ответ 8

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

Ответ 9

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

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

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

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

Ответ 10

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

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

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

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

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

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

Самый простой способ:

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

Ответ 11

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

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

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

Ответ 12

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

Ответ 13

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

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

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

Ответ 14

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

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

Ответ 15

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

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

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

Ответ 16

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

  • Пользователь вводит имя пользователя и адрес электронной почты
  • Отправлено по электронной почте с ссылкой с параметром url и guid, который был сохранен в db с истечением 48 часов.
  • Пользователь подтверждает пароль как reset
  • Новый пароль отправляется пользователю по электронной почте
  • Вход с новым паролем отображает сообщение или перенаправляет страницу смены пароля.

Ответ 17

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

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