Лучший способ реализации «забытого пароля»? [закрыто]

Я ищу лучший способ реализации "забытого пароля" особенность.

Я выступаю с 2 идеями:

When user click on forgot password, the user is required to key in the username, email and maybe date of birth or last name. Then a mail with temporary password will be sent to the user email account. The user uses the temporary password to login and resets his password.

Similar, but the email would contain a link to let the user reset his password.

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

 Félix Gagnon-Grenier07 июн. 2016 г., 16:53
@ Где бы ни была волна "давайте" удалим этот закрытый вопрос, потому что XYZ " на мета эти месяцы. Я просто хотел бы заявить, что этот конкретный вопрос не следует удалять, если только не будет доказано, что решения имеют недостатки и что его существование в буквальном смысле наносит больший вред, чем помогает делу безопасности.
 megaflop12 мая 2017 г., 14:23
OWASP "шпаргалка" для стратегии восстановления забытого пароля:owasp.org/index.php/…
 McDowell09 июл. 2009 г., 11:29
Я повторно пометил сообщение, поскольку оно выходит за рамки JSF - таким образом вы, вероятно, получите больше ответов.

Ответы на вопрос(10)

Ask user for email, check email is registered Generate GUID, and send it to that email Do not reset password yet User clicks link, and then have to enter new pass Reset password only after user is in your site, and have clicked reset button after typing new pass. Make that GUID expirable within a short time period to make it safer.
 22 нояб. 2013 г., 14:26
-1 за неиспользование какого-либо хэша в ссылке, которую вы отправляете человеку
 09 сент. 2011 г., 16:35
Я не хочу попасть в беду, спрашивая? но это связано с вашим ответом. Как вы генерируете GUID?

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

(Если база данных не взломана, но тогда ничего не безопасно).

которые предоставляют информацию о сбросе пароля:

http://jtauber.com/blog/2006/03/20/account_management_patterns/

(Don't let users confirm using GET):http://www.artima.com/forums/flat.jsp?forum=106&thread=152805&start=15&msRange=15

http://fishbowl.pastiche.org/archives/docs/PasswordRecovery.pdf

Надеюсь, это поможет. Они наверняка помогли мне понять проблему.

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

The user navigates to the 'forgot my password' page and enters their username or email (whichever is unique) to request a password reset.

Optionally at this stage you can confirm the request by asking for additional information such as the answer to a predefined security question or their date of birth etc. This extra level stops users receiving emails they didn't request.

Look up the user's account. Save a temporary password (usually a GUID) and timestamp against the account record. Send an email to the user containing the temporary password.

The user either clicks on the link containing the temporary password and the user's identifier in the email or navigates to the 'forgot my password' page and copy & pastes the temporary password and their identifier. The user enters their new password and confirms it.

Look up the user's record and if the current time is within a specified time limit (e.g. 1 hour) of the timestamp saved in step 2 then hash and save the new password. (Obviously only if the temporary passwords match!). Delete the temporary GUID and timestamp.

Принципиальным моментом здесь является то, что пользователю отправляется по электронной почте временный пароль, который позволяет емуchange их пароль. Первоначально сохраненный пароль (его следует хешировать!) Никогда не заменяется временным паролем, если пользователь его запомнил.

The original password will never be displayed to the user as it should be hashed and unknown.

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

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

Воздержитесь от отправки любой личной информации, такой как пароли и информация о доходах, по электронной почте, так как она может стать ОЧЕНЬ СМЕЩАЮЩЕЙ для вас и вашей организации в случае утечки или кражи такой информации. Серьезно подумайте о безопасности. Требуется только один инцидент, чтобы все кирпичи упали.

As for password retrieval, thoroughly read Забыли пароль.

The bottom line is that an application following best practices should allow a user to reset his own password. Personal security questions should be used. The application should not send email, display passwords, nor set any temporary passwords.

РЕДАКТИРОВАТЬ: Обновленная ссылка

 09 июл. 2009 г., 15:12
 24 окт. 2013 г., 08:52
ссылка снова мертва
 09 сент. 2011 г., 16:40
Я попробовал ссылку для Забытых паролей Best Practices и получил 500 ошибок сервера. Как вы думаете, сервер сейчас не работает или есть другая ссылка?
 14 сент. 2011 г., 15:54
 02 февр. 2014 г., 17:38

если он генерируется автоматически. Лучший подход (рекомендуется и используется SANS и другими):

On the forgot password page, ask the email/user id and a NEW password from the user. Email a link to the stored email for that account with an activation link. When the user clicks on that link, enable the new password.

Если он не щелкает ссылку в течение 24 часов или около того, отключите ее (чтобы она больше не меняла пароль).

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

 27 нояб. 2015 г., 17:59
Еще одна проблема! предоставление нового пароля на время сброса пароля не является хорошим вариантом. Я могу забыть новый пароль еще раз, если проверил мою электронную почту в нерабочее время!
 28 июл. 2010 г., 16:03
Я занимаюсь этой техникой. Атакующий вводит вашу электронную почту и новый пароль. Владелец аккаунта получает письмо, что-то неправильно читает и нажимает на ссылку. Злоумышленник, находящийся в режиме ожидания и пробующий новый пароль каждую минуту, получает доступ к учетной записи, пока владелец учетной записи не поймет, что произошло, и в конечном итоге не перейдет к «забытому паролю». стр.

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

[T]here are two common approaches:

Generate a new password on the server and email it Email a unique URL which will facilitate a reset process

Despite plenty of guidance to the contrary, the first point is really not where we want to be. The problem with doing this is that it means a persistent password – one you can go back with and use any time – has now been sent over an insecure channel and resides in your inbox.

...

But there’s one more big problem with the first approach in that it makes the malicious lockout of an account dead simple. If I know the email address of someone who owns an account at a website then I can lock them out of it whenever I please simply by resetting their password; it’s denial of service attack served up on a silver platter! This is why a reset is something that should only happen after successfully verifying the right of the requestor to do so.

When we talk about a reset URL, we’re talking about a website address which is unique to this specific instance of the reset process.

...

What we want to do is create a unique token which can be sent in an email as part of the reset URL then matched back to a record on the server alongside the user’s account thus confirming the email account owner is indeed the one attempting to reset the password. For example, the token may be “3ce7854015cd38c862cb9e14a1ae552b” and is stored in a table alongside the ID of the user performing the reset and the time at which the token was generated (more on that in a moment). When the email is sent out, it contains a URL such as “Reset/?id=3ce7854015cd38c862cb9e14a1ae552b” and when the user loads this, the page checks for the existence of the token and consequently confirms the identity of the user and allows the password to be changed.

...

The other thing we want to do with a reset URL is to time limit the token so that the reset process must be completed within a certain duration, say within an hour.

...

Finally, we want to ensure that this is a one-time process. Once the reset process is complete, the token should be deleted so that the reset URL is no longer functional. As with the previous point, this is to ensure an attacker has a very limited window in which they can abuse the reset URL. Plus of course the token is no longer required if the reset process has completed successfully.

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

The point of all these questions is the same: a backup password. If you forget your password, the secret question can verify your identity so you can choose another password or have the site e-mail your current password to you. It's a great idea from a customer service perspective -- a user is less likely to forget his first pet's name than some random password -- but terrible for security. The answer to the secret question is much easier to guess than a good password, and the information is much more public.

 21 июл. 2017 г., 01:19
@knarfancho Исправлено, спасибо!
 20 июл. 2017 г., 15:13
Ссылка на статью Троя Ханта изменилась. Идти кtroyhunt.com/everything-you-ever-wanted-to-know
 11 сент. 2014 г., 10:44
Эта ссылка содержит четкие изображения NSFW, есть ссылка, чтобы изменить это, но многие люди сначала сканируют страницу. Тупая идея!

Update: revised in May 2013 for a better approach

The user enters his username and hits "forgot password". I also recommend the option of entering the email address instead of the username, because usernames are sometimes forgotten too. The system has a table password_change_requests with the columns ID, Time and UserID. When the new user presses the button, a record is created in the table. The Time column contains the time when the user pressed the "Forgot Password" button. The ID is a string. A long random string is created (say, a GUID) and then hashed like a password (which is a separate topic in and of itself). This hash is then used as the 'ID' in the table. The system sends an email to the user which contains a link in it. The link also contains the original ID string (before the hashing). The link will be something like this: http://www.mysite.com/forgotpassword.jsp?ID=01234567890ABCDEF. The forgotpassword.jsp page should be able to retrieve the ID parameter. Sorry, I don't know Java, so I can't be more specific. When the user clicks the link in the email, he is moved to your page. The page retrieves the ID from the URL, hashes it again, and checks against the table. If such a record is there and is no more than, say, 24 hours old, the user is presented with the prompt to enter a new password. The user enters a new password, hits OK and everyone lives happily ever after... until next time!
 26 мая 2011 г., 10:04
наиболее подходящий способ реализовать это - отправить временный токен сброса пароля в виде электронного письма пользователю в виде простого текста (но никогда не сохранять его в виде простого текста в БД) - после того, как пользователь введет этот временный код, немедленно вынудите его повторно введите новый пароль. - для параноика, убедитесь, что на вашем SMTP-сервере есть ssl, чтобы ваши письма, содержащие конфиденциальную информацию, не отслеживались. в большинстве случаев такой подход довольно безопасен. если ваше дело требует дополнительной безопасности, у вас, вероятно, не должно быть пользователей, которые забывают свои пароли: S
 22 нояб. 2013 г., 14:30
по сути это описанный способ правильного сброса пароляcrackstation.net/hashing-security.htm#faq
 16 июл. 2013 г., 12:31
Зачем генерировать случайную строку / guid, хешировать ее и использовать хеш? Не хватает ли гида?
 16 июл. 2013 г., 20:21
@jeroenk - чтобы кто-то украл вашу БД, он не может подделать & quot; Сбросить пароль & quot; связать и изменить чей-либо пароль.
 19 дек. 2015 г., 14:55
@ Давид - Ах, я хотел отредактировать сообщение, но тема заблокирована. :( Хорошо, давайте попробуем еще раз: ваша таблица будет содержать столбцы:ID, UserID, Time, TokenHash, Вы будете генерировать две длинные случайные строки. Поместите первую строку («id») вID колонка; второй хэш («токен») и поместите хеш вTokenHash колонка. Сгенерировать ссылку какforogotPassword.jsp?id=asdasd&token=asdasd, Токен в ссылке НЕ хэшируется. Имеет ли это смысл сейчас?

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

Displaying half of the temporary password when the user's identity has been confirmed (security question, email address etc.) then the other half being sent to the email account. If the email account has been compromised, it is unlikely that the same person has also managed to perform a man-in-the middle attack. (Seen on UK Goverment Gateway)

Confirming identity via email and another medium - for example a code sent via text to a registered mobile. (Seen on eBay / PayPal)

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

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

Тогда достаточно просто отправить ссылку на временную страницу, которая позволяет человеку сменить пароль. (разрешить 24 часа или меньше)

Учетная запись электронной почты пользователя является самой слабой ссылкой в этом сценарии.

Ваш ответ на вопрос