nonce가있는 이메일의 활성화 / 등록 / 암호 재설정 링크에 대한 모범 사례는 무엇입니까?

nonce가있는 이메일의 활성화 / 등록 / 암호 재설정 링크에 대한 모범 사례는 무엇입니까?

---

애플리케이션은 사용자 계정을 확인하거나 비밀번호를 재설정하기 위해 이메일을 보냅니다. 나는 다음이 그것이되어야한다고 믿고 참조와 구현을 요청하고 있습니다.

애플리케이션이 사용자의 주소를 확인하기 위해 이메일로 링크를 보내야하는 경우, 내 견해에 따르면 링크 및 애플리케이션의 링크 처리 특성은 다음과 같아야합니다.

1. 링크 의 요청 URI ( )에 nonce 가 포함되어 있습니다 http://host/path?nonce.
2. 링크 (GET)를 따라 가면 사용자에게 선택적으로 nonce와 함께 양식이 표시됩니다.
3. 사용자가 입력 (POST)을 확인합니다.
4. 서버는 요청을 받고
   • 입력 매개 변수를 확인합니다.
   • 변경을 수행하고,
   • nonce를 무효화합니다.

이는 안전 및 멱 등성 메서드에 대한 HTTP RFC에 따라 정확해야합니다 .

문제는이 프로세스가 하나의 추가 페이지 또는 사용자 작업 (항목 3)을 포함한다는 것입니다.이 작업은 많은 사람들이 불필요한 것으로 간주됩니다 (쓸모없는 것은 아니지만). 이 접근 방식을 동료와 고객에게 제시하는 데 문제가 있었기 때문에 더 광범위한 기술 그룹에 이에 대한 의견을 요청하고 있습니다. POST 단계를 건너 뛰는 것에 반대했던 유일한 주장은 브라우저에서 링크를 미리로드 할 수 있다는 것입니다.

• 아이디어를 더 잘 설명하고 비전문가도 설득 할 수있는이 주제에 대한 참조가 있습니까 (저널, 블로그 등의 모범 사례)?
• 이 접근 방식을 구현하는 참조 사이트 (가급적 인기 있고 많은 사용자에게 있음)가 있습니까?
  • 그렇지 않은 경우 문서화 된 이유 또는 이에 상응하는 대안이 있습니까?

감사합니다,
카리 엠

---

아끼는 세부 사항

주요 부분은 짧게 유지했지만 의도적으로 생략 한 세부 사항에 대한 너무 많은 논의를 줄이기 위해 몇 가지 가정을 추가하겠습니다.

• 이메일의 내용은이 토론의 일부가 아닙니다. 사용자는 작업을 수행하려면 링크를 클릭해야한다는 것을 알고 있습니다. 사용자가 반응하지 않으면 아무 일도 일어나지 않습니다.
• 사용자에게 메일을 보내는 이유나 통신 정책을 표시 할 필요가 없습니다. 사용자가 이메일 수신을 기대한다고 가정합니다.
• nonce에는 만료 타임 스탬프가 있으며 중복을 줄이기 위해 수신자 이메일 주소와 직접 연결됩니다.

---

메모

OpenID 등을 통해 일반 웹 애플리케이션은 표준 사용자 계정 관리 (비밀번호, 이메일 등)를 구현하지 않아도되지만 여전히 일부 고객은 ' 자신의 사용자 '를 원합니다.

이상하게도 아직 여기에서 만족스러운 질문이나 답변을 찾지 못했습니다. 지금까지 내가 찾은 것 :

• URL 쿼리 매개 변수가 있는 HTTP POST 에서 Don의 답변 — 좋은 생각인가요?
• Thomas의 질문-POST를 언제 사용하고 언제 GET을 사용합니까?

---

이 질문은 ASP.NET (C #)에서 안전하고 고유 한 "일회용"활성화 URL 구현 과 매우 유사합니다 .

내 대답은 귀하의 계획에 가깝습니다. 짧은 유효 기간, 이중 가입 처리 등과 같은 몇 가지 문제가 지적되었습니다
. 암호화 임시 값을 사용하는 것도 중요합니다. 많은 사람들이 건너 뛰는 경향이 있습니다. GUID 사용 "...

당신이 제기하는 한 가지 새로운 요점은 여기서 중요한 점은 GET의 멱 등성입니다.
나는 당신의 일반적인 의도에 동의하지만 멱 등성이 일회성 링크와 직접적으로 모순된다는 것은 분명합니다. 이는 이와 같은 일부 상황에서 필수입니다.

나는 이것이 실제로 GET의 멱 등성을 위반하지 않는다고 가정하고 싶었지만 불행히도 ... 반면에 RFC는 GET이 반드시 멱 등성을 가져야 한다고 말합니다 . 따라서이 경우에는 포기하고 일회성 자동 무효화 링크를 고수합니다.

당신이 경우 정말 (?)이 아닌 나무 등으로 얻을 GET을 엄격한 RFC 준수 목표, 그리고하려면, 당신은 GET 페이지는 POST를 자동으로 제출 할 수 있습니다 - 현물 RFC의 비트 주위에 허점하지만 합법적하고, 사용자에게 이중 옵트 인을 요구할 필요가 없으며 그를 괴롭히지 않습니다.

미리로드에 대해 걱정할 필요가 없습니다 (CSRF 또는 브라우저 최적화 프로그램에 대해 이야기하고 있습니까?) ... CSRF는 nonce 때문에 쓸모가 없으며 최적화 프로그램은 일반적으로 미리로드 된 페이지에서 자바 스크립트 (자동 제출에 사용)를 처리하지 않습니다.

---

비밀번호 재설정 정보 :

사용자의 등록 된 이메일 주소로 이메일을 전송하여이를 수행하는 관행은 실제로는 매우 일반적이지만 좋은 보안은 아닙니다. 이렇게하면 애플리케이션 보안이 사용자의 이메일 제공 업체에 완전히 아웃소싱됩니다. 필요한 암호의 길이와 사용하는 영리한 암호 해싱은 중요하지 않습니다. 이메일 계정에 대한 액세스 권한이 있거나 사용자에게 전달되는 모든 곳에서 암호화되지 않은 이메일을 읽을 수 있다면 사용자에게 발송 된 이메일을 읽어 귀하의 사이트에 들어갈 수 있습니다 (예 : 사악한 시스템 관리자).

이것은 문제가되는 사이트의 보안 요구 사항에 따라 중요 할 수도 있고 중요하지 않을 수도 있지만, 사이트 사용자로서 저는 안전하지 않다고 생각하기 때문에 최소한 그러한 비밀번호 재설정 기능을 비활성화 할 수 있기를 원할 것입니다.

주제를 논의하는 이 백서 를 찾았습니다 .

안전한 방법으로 수행하는 방법의 짧은 버전 :

1. 계정에 대한 확실한 사실 요구

   1. 사용자 이름.
   2. 이메일 주소.
   3. 10 자리 계좌 번호 또는 사회 보장 번호와 같은 기타 정보.

2. 사용자가 사소 할 수없는 3 개 이상의 사전 정의 된 질문에 답해야합니다 (사용자가 미리 정의한 질문은 사용자가 자신의 질문을 만들지 않도록합니다). "좋아하는 색이 뭐야"가 아니라 "가장 좋아하는 휴가지가 뭐야"처럼.

3. 선택 사항 : 사용자가 입력해야하는 미리 정의 된 이메일 주소 또는 셀 번호 (SMS)로 확인 코드를 보냅니다.

4. 사용자가 새 암호를 입력하도록 허용합니다.

---

일반적으로 아래 제안 된 수정 사항에 동의합니다.

1. 사용자는 이메일을 제공하여 귀하의 사이트에 등록합니다.
2. Verification email is sent to the users account with two links: a) One link with the GUID to verify the registration b) One link with the GUID to reject the verification
3. When they visit the verification url from their email they are automatically verified and the verification guid is marked as such in your system.
4. When they visit the rejection url from their email they are automatically removed from the queue of possible verifications but more importantly you can tell the user that you are sorry for the email registration and give them further options such as removing their email from your system. This will stop any custom service type complaints about someone entering my email in your system...blah blah blah.

Yes, you should assume that when they click the verification link that they are verified. Making them click a second button in a page is a bit much and only needed for double opt in style registration where you plan to spam the person that registered. Standard registration/verification schemes don't usually require this.

참고URL : https://stackoverflow.com/questions/1066611/what-are-best-practices-for-activation-registration-password-reset-links-in-emai