'비밀번호를 잊어 버린'구현을위한 가장 좋은 방법은?

'비밀번호를 잊어 버린'구현을위한 가장 좋은 방법은? [닫은]

---

"비밀번호를 잊어 버렸습니다"기능을 구현하는 가장 좋은 방법을 찾고 있습니다.

두 가지 아이디어가 나옵니다.

1. 사용자가 비밀번호를 잊어 버렸을 때, 사용자는 사용자 이름, 이메일 및 생년월일 또는 성을 입력해야합니다. 그런 다음 임시 비밀번호가 포함 된 메일이 사용자 이메일 계정으로 전송됩니다. 사용자는 임시 비밀번호를 사용하여 로그인하고 비밀번호를 재설정합니다.

2. 비슷하지만 이메일에는 사용자가 비밀번호를 재설정 할 수있는 링크가 포함되어 있습니다.

아니면 아무도 나에게 더 좋고 안전한 방법을 제안 할 수 있습니까? 또한 임시 비밀번호 또는 링크를 보내거나 24 시간 이내에 사용자가 비밀번호를 재설정하도록 강제하지 않으면 임시 비밀번호 또는 링크를 사용할 수 없습니다. 그렇게하는 방법?

---

업데이트 : 더 나은 접근 방식을 위해 2013 년 5 월 개정

1. 사용자는 자신의 사용자 이름을 입력하고 "암호를 잊어 버렸습니다". 또한 사용자 이름도 잊어 버리기 때문에 사용자 이름 대신 이메일 주소를 입력하는 옵션을 권장합니다.
2. 이 시스템은 테이블이 password_change_requests컬럼과를 ID, Time하고 UserID. 새 사용자가 버튼을 누르면 테이블에 레코드가 작성됩니다. 이 Time열에는 사용자가 "비밀번호 분실"버튼을 누른 시간이 포함됩니다. 은 ID문자열입니다. 긴 임의의 문자열 (예 : GUID)이 생성 된 다음 암호 (해당 항목 자체)와 같이 해시 됩니다. 이 해시는 테이블에서 'ID'로 사용됩니다.
3. 시스템은 사용자에게 링크가 포함 된 이메일을 보냅니다. 링크에는 원래 ID 문자열 (해시 전)도 포함됩니다. 링크는 다음과 같습니다 : http://www.mysite.com/forgotpassword.jsp?ID=01234567890ABCDEF. forgotpassword.jsp 페이지는 ID 매개 변수를 검색 할 수 있어야합니다. 죄송합니다. Java를 모르므로 더 구체적으로 말할 수 없습니다.
4. 사용자가 이메일에서 링크를 클릭하면 페이지로 이동합니다. 이 페이지 ID는 URL에서 URL을 검색하여 다시 해시하고 테이블을 확인합니다. 이러한 레코드가 있고 24 시간이 지나지 않은 경우 사용자 에게 새 비밀번호를 입력하라는 프롬프트가 표시됩니다 .
5. 사용자가 새 비밀번호를 입력하고 확인을 누르면 다음 번까지 모든 사람이 행복하게 살 수 있습니다!

---

그것은 모두 귀하의 사이트와 달성하려는 보안 수준에 달려 있지만 웹 앱의 기본 프로세스는 다음과 같습니다.

1. 사용자는 '비밀번호를 잊어 버렸습니다'페이지로 이동하여 사용자 이름 또는 이메일 (고유 한)을 입력하여 비밀번호 재설정을 요청합니다.

2. 선택적으로이 단계에서 사전 정의 된 보안 질문에 대한 답변 또는 생년월일 등과 같은 추가 정보를 요청하여 요청을 확인할 수 있습니다.이 추가 레벨은 사용자가 요청하지 않은 이메일을받지 못하게합니다.

3. 사용자 계정을 찾으십시오. 임시 비밀번호 (일반적으로 GUID)와 타임 스탬프를 계정 레코드에 저장하십시오. 임시 비밀번호가 포함 된 이메일을 사용자에게 보냅니다.

4. 사용자는 이메일에 임시 비밀번호와 사용자의 식별자가 포함 된 링크를 클릭하거나 '내 비밀번호를 잊어 버렸습니다'페이지로 이동하여 임시 비밀번호와 해당 식별자를 복사하여 붙여 넣습니다. 사용자는 새 비밀번호를 입력하고 확인합니다.

5. 사용자의 레코드를 검색하고 현재 시간이 2 단계에서 저장된 시간 소인의 지정된 시간 제한 (예 : 1 시간) 내에있는 경우 새 비밀번호를 해시하고 저장하십시오. (임시 암호가 일치하는 경우에만!). 임시 GUID 및 타임 스탬프를 삭제하십시오.

여기서 사용자는 비밀번호를 변경할 수있는 임시 비밀번호를 이메일로 발송 합니다. 원래 저장된 비밀번호 (해시해야 함)는 사용자가 기억할 경우를 대비해 임시 비밀번호로 변경되지 않습니다.

원래 비밀번호는 해시 및 알 수 없으므로 사용자에게 표시되지 않습니다.

참고 이 과정은 사용자의 이메일 계정의 보안에 전적으로 의존하고있다. 따라서 달성하려는 보안 수준에 따라 다릅니다. 일반적으로 대부분의 사이트 / 앱에 충분합니다.

---

트로이 헌트 (Troy Hunt)는 그의 기사에서 보안 암호 재설정 기능 구축에 대해 알고 싶었던 모든 것을 지적 합니다 . 가장 관련된 발췌는 다음과 같습니다.

[T] 일반적인 두 가지 접근 방식이 있습니다.

1. 서버에서 새 비밀번호를 생성하고 이메일로 전송
2. 재설정 프로세스를 용이하게하는 고유 한 URL을 이메일로 보냅니다.

반대에 대한 많은 지침에도 불구하고 첫 번째 요점은 실제로 우리가 원하는 곳이 아닙니다. 이 작업을 수행하는 데있어 문제는 암호를 다시 사용하고 언제든지 사용할 수있는 영구 암호가 안전하지 않은 채널을 통해 전송되어받은 편지함에 있다는 것입니다.

...

그러나 첫 번째 접근 방식에는 계정의 악의적 인 잠금이 간단하게 중단된다는 점에서 또 하나의 큰 문제가 있습니다. 웹 사이트에서 계정을 소유 한 사람의 이메일 주소를 알고 있다면 비밀번호를 재설정하여 원할 때마다 이메일 주소를 잠글 수 있습니다. 실버 플래터에 제공되는 서비스 거부 공격입니다! 이것이 재설정자가 요청자의 권한을 성공적으로 확인한 후에 만 ​​발생해야하는 이유입니다.

재설정 URL에 대해 이야기 할 때, 재설정 프로세스의이 특정 인스턴스에 고유 한 웹 사이트 주소에 대해 이야기합니다.

...

우리가하고 싶은 것은 재설정 URL의 일부로 이메일로 전송 된 다음 사용자 계정과 함께 서버의 레코드와 다시 일치시킬 수있는 고유 한 토큰을 생성하여 이메일 계정 소유자가 실제로 재설정하려는 사람임을 확인하는 것입니다. 암호. 예를 들어, 토큰은 "3ce7854015cd38c862cb9e14a1ae552b"일 수 있으며 리셋을 수행하는 사용자의 ID 및 토큰이 생성 된 시간과 함께 테이블에 저장됩니다 (자세한 내용은 더 자세히 설명). 이메일이 발송 될 때 "Reset /? id = 3ce7854015cd38c862cb9e14a1ae552b"와 같은 URL을 포함하고 있으며 사용자가이를로드하면 페이지에서 토큰의 존재를 확인하고 결과적으로 사용자의 신원을 확인하고 비밀번호를 허용합니다. 변경됩니다.

...

재설정 URL을 사용하여 수행하려는 다른 작업은 특정 시간 (예 : 1 시간) 내에 재설정 프로세스를 완료해야 토큰을 시간 제한하는 것입니다.

...

마지막으로, 이것이 일회성 프로세스인지 확인하고 싶습니다. 재설정 프로세스가 완료되면 재설정 URL이 더 이상 작동하지 않도록 토큰을 삭제해야합니다. 이전 시점과 마찬가지로 공격자가 재설정 URL을 악용 할 수있는 창이 매우 제한되어 있습니다. 또한 재설정 프로세스가 성공적으로 완료된 경우 토큰이 더 이상 필요하지 않습니다.

He makes many more good points about avoiding information leaks, CAPTCHAs, two-factor authentication, and of course the basic best practices like password hashing. I think it's important to note that I disagree with Troy on the usefulness of security questions, preferring Bruce Schneier's skepticism of the practice:

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.

---

I'll go with:

1. Ask user for email, check email is registered
2. Generate GUID, and send it to that email
3. Do not reset password yet
4. User clicks link, and then have to enter new pass
5. Reset password only after user is in your site, and have clicked reset button after typing new pass.
6. Make that GUID expirable within a short time period to make it safer.

---

When you are sending any information via email, it won't be secure. There are too many ways someone can get it. It would be child's play for a skilled hacker looking to steal your information.

Refrain from sending any personal information like passwords and income information via email as it can become VERY EMBARRASSING for you and your organization if such information was leaked or stolen. Think about security seriously. It just takes that one incident for all the bricks to fall.

As for password retrieval, thoroughly read Forgot Password Best Practices.

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.

EDIT: Updated link

---

As said, it depends on the level of security required, however, if you need a higher level, some novel solutions I have seen include;

• 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)

For somewhere in between these two extremes implementing security questions may be the way to go as mentioned by DaveG.

---

If you include an email address with the registration. The "forget password" button sends an email to that email address. It ensures that the information is send to a trusted email.

(Unless the database is hacked, but then nothing is safe).

---

Here are three very good links that provide information on password resets:

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

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

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

Hope that helps. They sure helped me understand the issue.

---

I would enforce unique email addresses across the accounts.

Then it is a simple matter of sending a link to a temporary page that allows the person to change their password. (allow 24 hours or less)

The user's email account is the weakest link in this scenario.

---

Never email a password to the user. Even if it is auto-generated. Best approach (recommend and used by SANS and others):

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

If he doesn't click the link within 24 hours or so, disable the link (so that it does not change the password anymore).

Never change the password without the user consent. It means do not email a new password just because someone clicked on the forgot password link and figured out the account name.

참고URL : https://stackoverflow.com/questions/1102781/best-way-for-a-forgot-password-implementation