양식 기반 웹 사이트 인증에 대한 확실한 가이드

 

질문 : 양식 기반 웹 사이트 인증에 대한 확실한 가이드

---

우리는 Stack Overflow가 매우 구체적인 기술적 질문에 대한 리소스 일뿐만 아니라 일반적인 문제의 변형을 해결하는 방법에 대한 일반적인 지침을 제공해야한다고 믿습니다. "웹 사이트에 대한 양식 기반 인증"은 이러한 실험에 적합한 주제 여야합니다.

• 로그인 방법
• 로그 아웃하는 방법
• 로그인 상태를 유지하는 방법
• 쿠키 관리 (권장 설정 포함)
• SSL / HTTPS 암호화
• 비밀번호 저장 방법
• 비밀 질문 사용
• 잊어 버린 사용자 이름 / 암호 기능
• 교차 사이트 요청 위조 (CSRF) 를 방지하기 위해 임시 값 사용
• OpenID
• "기억하기"확인란
• 사용자 이름 및 암호의 브라우저 자동 완성
• 비밀 URL (다이제스트로 보호되는 공용 URL)
• 비밀번호 안전성 확인
• 이메일 검증
• 그리고 폼 기반 인증 에 대해 훨씬 더 ...

• 역할 및 권한
• HTTP 기본 인증

답변

---

인증을 위해 서버 측의 스크립트에 값을 게시하는 로그인 + 암호 HTML 양식을 작성하는 방법을 이미 알고 있다고 가정합니다. 아래 섹션에서는 건전한 실제 인증 패턴과 가장 일반적인 보안 위험을 피하는 방법을 다룹니다.

HTTPS로 또는 HTTPS로?

연결이 이미 안전하지 않은 경우 (즉, SSL / TLS를 사용하여 HTTPS를 통해 터널링 됨) 로그인 양식 값이 일반 텍스트로 전송되어 브라우저와 웹 서버 사이의 라인을 도청하는 모든 사람이 통과 할 때 로그인을 읽을 수 있습니다. 을 통하여. 이러한 유형의 도청은 정부에서 일상적으로 수행하지만 일반적으로 '소유'전선은 HTTPS를 사용하는 것 외에는 다루지 않습니다.

본질적으로 로그인 중에 도청 / 패킷 스니핑을 방지하는 유일한 실질적인 방법은 HTTPS 또는 다른 인증서 기반 암호화 체계 (예 : TLS ) 또는 검증되고 테스트 된 시도 응답 체계 (예 : Diffie-Hellman)를 사용하는 것입니다. 기반 SRP). 다른 방법은 도청 공격자 가 쉽게 우회 할 수 있습니다.

물론 약간 비실용적이라면 어떤 형태의 이중 인증 체계 (예 : Google Authenticator 앱, 물리적 '냉전 스타일'코드북 또는 RSA 키 생성기 동글)를 사용할 수도 있습니다. 올바르게 적용하면 보안되지 않은 연결에서도 작동 할 수 있지만 개발자가 SSL이 아닌 이중 인증을 구현할 것이라고 상상하기는 어렵습니다.

(금지) 자체 자바 스크립트 암호화 / 해싱 롤링

주어 인식 (지금은 비록 피할 수 ) 비용과 웹 사이트에 SSL 인증서를 설정하는 기술적 어려움은, 일부 개발자는 보안되지 않은 회선을 통해 일반 텍스트 로그인을 통과 피하기 위해 자신의 브라우저 해시 또는 암호화 체계를 롤 유혹.

이것은 고상한 생각이지만, 위의 항목 중 하나와 결합하지 않는 한 본질적으로 쓸모가 없습니다 ( 보안 결함이 될 수 있음). 즉, 강력한 암호화로 회선을 보호하거나 검증 된 도전 응답을 사용하는 것입니다. 메커니즘 (그게 무엇인지 모르는 경우 가장 증명하기 어렵고, 설계하기 가장 어렵고, 디지털 보안에서 개념을 구현하기 가장 어려운 것 중 하나라는 것을 알고 있어야합니다).

암호를 해싱하는 것이 암호 공개 에 대해 효과적 일 수 있다는 것은 사실이지만 재생 공격, Man-In-The-Middle 공격 / 도용 (공격자가 보안되지 않은 HTML 페이지에 도달하기 전에 몇 바이트를 삽입 할 수있는 경우)에 취약합니다. 브라우저에서는 단순히 JavaScript에서 해싱을 주석 처리하거나 무차별 대입 공격 (공격자에게 사용자 이름, 솔트 및 해시 된 암호를 모두 제공하기 때문에)을 주석 처리 할 수 있습니다.

인류에 대한 보안 문자

CAPTCHA 는 하나의 특정 공격 범주 인 자동화 된 사전 / 무력한 시행 착오를 작업자없이 차단하기위한 것입니다. 이것이 진짜 위협이라는 것은 의심의 여지가 없지만 CAPTCHA, 특히 적절하게 설계된 서버 측 로그인 제한 체계가 필요하지 않은 원활하게 처리하는 방법이 있습니다. 이에 대해서는 나중에 논의 할 것입니다.

CAPTCHA 구현은 비슷하게 생성되지 않습니다. 그들은 종종 인간이 해결할 수 없으며, 대부분은 실제로 봇에 대해 비효율적이며, 모두 값싼 제 3 세계 노동에 대해 비효율적이며 ( OWASP 에 따르면 현재 작업장 요금은 500 회 테스트 당 $ 12입니다) 일부 구현은 다음과 같을 수 있습니다. 일부 국가에서는 기술적으로 불법입니다 ( OWASP 인증 치트 시트 참조). CAPTCHA를 사용해야하는 경우 Google의 reCAPTCHA를 사용하세요. 정의상 OCR이 어렵고 (이미 OCR로 잘못 분류 된 도서 스캔을 사용하기 때문에) 사용자 친화적이려고 매우 노력하기 때문입니다.

개인적으로 저는 CAPTCHAS가 짜증나는 경향이 있으며 사용자가 여러 번 로그인에 실패하고 제한 지연이 최대 일 때 마지막 수단으로 만 사용합니다. 이것은 수용 할 수있을 정도로 거의 발생하지 않으며 시스템 전체를 강화합니다.

비밀번호 저장 / 로그인 확인

이것은 최근 몇 년간 우리가 목격 한 모든 고도로 공개 된 해킹과 사용자 데이터 유출 이후에 마침내 상식이 될 수 있지만, 데이터베이스에 암호를 일반 텍스트로 저장하지 마십시오. 사용자 데이터베이스는 SQL 주입을 통해 일상적으로 해킹, 유출 또는 수집되며, 원시 일반 텍스트 암호를 저장하는 경우 로그인 보안을 위해 즉시 게임이 종료됩니다.

따라서 비밀번호를 저장할 수없는 경우 로그인 양식에서 게시 된 로그인 + 비밀번호 조합이 올바른지 어떻게 확인합니까? 대답은 키 유도 함수를 사용하여 해싱하는 것입니다. 새 사용자가 생성되거나 암호가 변경 될 때마다 암호를 가져와 Argon2, bcrypt, scrypt 또는 PBKDF2와 같은 KDF를 통해 실행하여 일반 텍스트 암호 ( "correcthorsebatterystaple")를 길고 임의의 문자열로 바꿉니다. , 데이터베이스에 저장하는 것이 훨씬 안전합니다. 로그인을 확인하려면 입력 한 암호에 대해 동일한 해시 함수를 실행합니다. 이번에는 솔트를 전달하고 결과 해시 문자열을 데이터베이스에 저장된 값과 비교합니다. Argon2, bcrypt 및 scrypt는 이미 해시와 함께 솔트를 저장합니다. 자세한 내용은 sec.stackexchange에 대한이 기사를 확인하십시오.

솔트가 사용되는 이유는 해싱 자체만으로는 충분하지 않기 때문입니다. 레인보우 테이블 로부터 해시를 보호하기 위해 소위 '솔트'를 추가하는 것이 좋습니다. 솔트는 정확히 일치하는 두 개의 암호가 동일한 해시 값으로 저장되는 것을 효과적으로 방지하여 공격자가 암호 추측 공격을 실행하는 경우 전체 데이터베이스가 한 번에 검색되는 것을 방지합니다.

사용자가 선택한 암호가 충분히 강력하지 않고 (즉, 일반적으로 엔트로피가 충분하지 않음) 암호 저장에 암호 해시를 사용해서는 안되며 해시에 액세스 할 수있는 공격자가 암호 추측 공격을 비교적 짧은 시간에 완료 할 수 있습니다. KDFs가 사용되는 이유이다 -이 효과적으로 "키 스트레칭" 1 만 배 느린 암호를 추측 공격자 원인 모든 암호가 공격자의 차종을 생각한다는 의미는 예를 들어, 10,000 번 해시 알고리즘의 여러 번 반복됩니다,.

세션 데이터- "Spiderman69로 로그인되었습니다"

서버가 사용자 데이터베이스에 대해 로그인 및 암호를 확인하고 일치하는 항목을 찾으면 시스템은 브라우저가 인증되었음을 기억할 방법이 필요합니다. 이 사실은 세션 데이터에 서버 측에만 저장되어야합니다.

세션 데이터에 익숙하지 않은 경우 작동 방식은 다음과 같습니다. 임의 생성 된 단일 문자열이 만료되는 쿠키에 저장되고 서버에 저장된 데이터 모음 (세션 데이터)을 참조하는 데 사용됩니다. MVC 프레임 워크를 사용하는 경우 의심 할 여지없이 이미 처리되었습니다.

가능하다면 세션 쿠키에 보안 및 HTTP 전용 플래그가 브라우저로 전송 될 때 설정되어 있는지 확인하십시오. HttpOnly 플래그는 XSS 공격을 통해 읽히는 쿠키에 대한 보호를 제공합니다. 보안 플래그는 쿠키가 HTTPS를 통해서만 다시 전송되도록 보장하므로 네트워크 스니핑 공격으로부터 보호합니다. 쿠키의 값은 예측할 수 없어야합니다. 존재하지 않는 세션을 참조하는 쿠키가 표시되는 경우 세션 고정 을 방지하기 위해 해당 값을 즉시 교체해야합니다.

세션 상태는 클라이언트 측에서도 유지 될 수 있습니다. 이는 JWT (JSON Web Token)와 같은 기술을 사용하여 달성됩니다.

영구 로그인 쿠키 ( "기억하기"기능)는 위험 영역입니다. 한편으로는 사용자가 처리 방법을 이해하면 기존 로그인만큼 전적으로 안전합니다. 다른 한편으로, 그들은 부주의 한 사용자의 손에 엄청난 보안 위험이 있습니다. 이들은 공용 컴퓨터에서이를 사용하고 로그 아웃하는 것을 잊어 버릴 수 있으며, 브라우저 쿠키가 무엇인지 또는 쿠키를 삭제하는 방법을 모를 수 있습니다.

개인적으로 정기적으로 방문하는 웹 사이트에 대한 영구 로그인을 좋아하지만 안전하게 처리하는 방법을 알고 있습니다. 사용자가 똑같이 알고 있다고 확신하는 경우 깨끗한 양심으로 영구 로그인을 사용할 수 있습니다. 그렇지 않다면 로그인 자격 증명에 부주의 한 사용자가 해킹을 당하면 스스로 가져 왔다는 철학에 가입 할 수 있습니다. 우리가 사용자의 집에 가서 모니터 가장자리에 줄 지어 놓은 암호를 사용하여 안면 손바닥을 유발하는 Post-It 메모를 모두 뜯어내는 것도 아닙니다.

물론 일부 시스템은 계정을 해킹 할 여유가 없습니다. 이러한 시스템의 경우 영구 로그인을 정당화 할 수있는 방법이 없습니다.

영구 로그인 쿠키를 구현하기로 결정한 경우 수행하는 방법은 다음과 같습니다.

1. 먼저 주제에 대한 Paragon Initiative의 기사 를 읽어보십시오. 많은 요소를 올바르게 가져와야하며이 기사는 각 요소를 잘 설명합니다.
2. 그리고 가장 일반적인 함정 중 하나를 반복하기 위해 데이터베이스에 영구 로그인 쿠키 (토큰)를 저장하지 말고 해시로만 저장하십시오! 로그인 토큰은 Password Equivalent이므로 공격자가 데이터베이스에 손을 대면 일반 텍스트 로그인-암호 조합 인 것처럼 토큰을 사용하여 모든 계정에 로그인 할 수 있습니다. 따라서 영구 로그인 토큰을 저장할 때 해싱을 사용하십시오 ( https://security.stackexchange.com/a/63438/5002 에 따르면 약한 해시는이 목적에 적합합니다).

 

 

'비밀 질문'을 구현하지 마십시오 . '비밀 질문'기능은 보안 안티 패턴입니다. 반드시 읽어야 할 목록에서 링크 번호 4의 문서를 읽으십시오. 사라 페일 린에게 야후! 그녀의 보안 질문에 대한 대답이 "와실 라 고등학교"였기 때문에 전 대통령 선거에서 이메일 계정이 해킹당했습니다!

사용자가 지정한 질문이 있더라도 대부분의 사용자는 다음 중 하나를 선택할 가능성이 높습니다.

• 어머니의 결혼 전 이름이나 좋아하는 애완 동물과 같은 '표준'비밀 질문
• 누구나 자신의 블로그, LinkedIn 프로필 또는 이와 유사한 프로필에서 들어 올릴 수있는 간단한 퀴즈
• 비밀번호를 추측하는 것보다 답하기 쉬운 질문입니다. 괜찮은 암호에 대해 상상할 수있는 모든 질문입니다.

 

결론적으로 보안 질문은 거의 모든 형태와 변형에서 본질적으로 안전하지 않으며 어떤 이유로 든 인증 체계에 사용해서는 안됩니다.

보안 질문이 실제로 존재하는 진정한 이유는 재 활성화 코드를 얻기 위해 이메일에 액세스 할 수없는 사용자의 몇 가지 지원 호출 비용을 편리하게 절약 할 수 있기 때문입니다. 이것은 보안과 Sarah Palin의 명성을 희생합니다. 그만한 가치가 있습니까? 아마 아닐 것입니다.

잊어 버린 / 분실 된 사용자 암호를 처리 하기 위해 보안 질문 을 사용해서는 안되는 이유를 이미 언급했습니다. 또한 사용자에게 실제 암호를 이메일로 보내서는 안된다는 것은 당연합니다. 이 분야에서 피해야 할 너무 흔한 함정이 적어도 두 가지 더 있습니다.

1. 잊어 버린 암호를 자동 생성 된 강력한 암호로 재설정 하지 마십시오. 이러한 암호는 기억하기 어렵 기 때문에 사용자가 모니터 가장자리에있는 밝은 노란색 포스트잇에 변경하거나 적어 두어야합니다. 새 비밀번호를 설정하는 대신 사용자가 즉시 새 비밀번호를 선택하도록 허용하세요. (이에 대한 예외는 사용자가 일반적으로 기록하지 않고는 기억할 수없는 암호를 저장 / 관리하기 위해 암호 관리자를 사용하는 경우입니다.)
2. 항상 데이터베이스에서 분실 한 암호 코드 / 토큰을 해시하십시오. 다시 말하지만 ,이 코드는 동등한 암호의 또 다른 예이므로 공격자가 데이터베이스에 손을 대면 해시해야합니다. 분실 한 비밀번호 코드가 요청되면 일반 텍스트 코드를 사용자의 이메일 주소로 보낸 다음 해시하고 데이터베이스에 해시를 저장 한 다음 원본 . 암호 또는 영구 로그인 토큰과 같습니다.

 

마지막 참고 사항 : '분실 된 비밀번호 코드'를 입력하기위한 인터페이스가 최소한 로그인 양식 자체만큼 안전한지 항상 확인하십시오. 그렇지 않으면 공격자가 액세스 권한을 얻기 위해 단순히 이것을 사용합니다. 매우 긴 '잃어버린 암호 코드'(예 : 대소 문자 구분 영숫자 16 자)를 생성하는 것이 좋습니다.하지만 로그인 양식 자체에 대해 수행하는 것과 동일한 제한 체계를 추가하는 것이 좋습니다.

먼저 현실 점검을 위해이 작은 기사를 읽고 싶을 것입니다. 가장 일반적인 500 개의 암호

좋아, 따라서 목록이 어느 시스템 에서나 가장 일반적인 암호 의 표준 목록이 아닐 수도 있지만 시행 된 정책이 없을 때 사람들이 얼마나 빈약하게 암호를 선택하는지 보여주는 좋은 지표입니다. 또한이 목록을 최근에 도난당한 암호에 대한 공개 된 분석과 비교할 때이 목록은 매우 집에 가까워 보입니다.

따라서 최소 암호 강도 요구 사항이 없으면 사용자의 2 %가 가장 일반적인 상위 20 개 암호 중 하나를 사용합니다. 의미 : 공격자가 20 번만 시도하면 웹 사이트의 50 개 계정 중 1 개가 크래킹 될 수 있습니다.

이를 방지하려면 암호의 엔트로피를 계산 한 다음 임계 값을 적용해야합니다. NIST (National Institute of Standards and Technology) 특별 출판물 800-63 에는 매우 좋은 제안이 있습니다. 즉, 사전 및 키보드 레이아웃 분석 (예 : 'qwertyuiop'은 잘못된 암호)과 결합하면 18 비트 엔트로피 수준에서 잘못 선택된 모든 암호의 99 %를 거부 할 수 있습니다. 단순히 암호 강도를 계산 하고 사용자에게 시각적 강도 측정기 를 보여주는 것은 좋지만 충분하지 않습니다. 시행되지 않는 한 많은 사용자가이를 무시할 가능성이 높습니다.

높은 엔트로피 암호의 사용자 친 화성을 새로 고취하려면 Randall Munroe의 암호 강도 xkcd 를 적극 권장합니다.

Troy Hunt의 Have I Been Pwned API 를 사용하여 공개 데이터 침해로 인해 손상된 비밀번호에 대해 사용자 비밀번호를 확인합니다.

먼저 숫자를 확인하세요. 비밀번호 복구 속도-비밀번호가 유지되는 기간

해당 링크의 표를 살펴볼 시간이 없다면 다음 목록을 참조하세요.

1. 주판으로 암호를 해독하더라도 취약한 암호를 해독하는 데 거의 시간 이 걸리지 않습니다.
2. 대소 문자를 구분하지 않으면 9 자리 영숫자 암호를 해독하는 데 거의 시간 이 걸리지 않습니다.
3. 8 자 미만 의 복잡한 기호와 문자와 숫자, 대소 문자 암호를 해독하는 데 거의 시간 이 걸리지 않습니다 (데스크톱 PC는 문제에서 최대 7 자까지 전체 키 스페이스를 검색 할 수 있습니다. 며칠 또는 몇 시간)
4. 그러나 초당 한 번의 시도로 제한되는 경우 6 자 암호조차도 해독하는 데 과도한 시간이 걸립니다!

 

이 숫자에서 무엇을 배울 수 있습니까? 글쎄요.하지만 우리는 가장 중요한 부분에 초점을 맞출 수 있습니다. 즉, 연속적인 많은 로그인 시도 (즉, 무차별 대입 공격)를 막는 것이 그렇게 어렵지 않다는 사실입니다. 그러나 그것을 옳게 방지하는 것은보기만큼 쉽지 않습니다.

일반적으로 무차별 대입 공격 (및 사전 공격)에 대해 모두 효과적인 세 가지 선택이 있습니다 . 그러나 이미 강력한 암호 정책을 사용하고 있으므로 문제가되지 않습니다 .

• N 번의 시도 실패 후 CAPTCHA 제시 (지옥처럼 짜증나고 종종 비효율적이지만 여기서 반복하고 있습니다)
• N 번의 시도 실패 후 계정 잠금 및 이메일 확인 필요 (이는 발생하기를 기다리는 DoS 공격)
• 그리고 마지막으로 로그인 제한 : 즉, N 번의 시도 실패 후 시도 사이의 시간 지연을 설정합니다 (예, DoS 공격은 여전히 가능하지만 적어도 가능성이 훨씬 적고 훨씬 더 복잡해집니다).

 

 

모범 사례 # 1 : 다음과 같이 실패한 시도 횟수에 따라 증가하는 짧은 시간 지연 :

• 1 회 실패 = 지연 없음
• 2 회 실패 = 2 초 지연
• 3 회 실패 = 4 초 지연
• 4 회 실패 = 8 초 지연
• 5 회 실패 = 16 초 지연
• 기타

이 체계를 공격하는 DoS는 결과적인 잠금 시간이 이전 잠금 시간의 합계보다 약간 더 크기 때문에 매우 비실용적입니다.

명확히하기 위해 : 지연은 브라우저에 응답을 반환하기 전 지연이 아닙니다. 특정 계정이나 특정 IP 주소로의 로그인 시도가 전혀 수락되거나 평가되지 않는 시간 초과 또는 다루기 힘든 기간과 비슷합니다. 즉, 올바른 자격 증명은 성공적인 로그인에서 반환되지 않으며 잘못된 자격 증명은 지연 증가를 유발하지 않습니다.

모범 사례 # 2 : N 번의 시도 실패 후 적용되는 중간 길이의 시간 지연입니다.

• 1-4 회 실패 = 지연 없음
• 5 회 실패 = 15-30 분 지연

이 계획을 공격하는 DoS는 매우 비실용적이지만 확실히 가능합니다. 또한 이러한 긴 지연은 합법적 인 사용자에게 매우 성 가실 수 있습니다. 건망증 사용자는 당신을 싫어할 것입니다.

모범 사례 # 3 : 두 가지 접근 방식 결합-N 번의 시도 실패 후 적용되는 고정 된 짧은 시간 지연입니다.

• 1-4 회 실패 = 지연 없음
• 5 회 이상의 실패 시도 = 20 초 지연

또는 다음과 같이 고정 된 상한이있는 지연 증가 :

• 1 회 실패 = 5 초 지연
• 2 회 실패 = 15 초 지연
• 3 회 이상의 실패 시도 = 45 초 지연

이 최종 계획은 OWASP 모범 사례 제안 (MUST-READ 목록의 링크 1)에서 가져 왔으며 제한적인 측면에서 인정 되더라도 모범 사례로 간주되어야합니다.

그러나 경험 상으로는 암호 정책이 강력할수록 지연으로 인해 사용자를 괴롭힐 필요가 줄어 듭니다. 강력한 (대소 문자 구분 영숫자 + 필수 숫자 및 기호) 9+ 문자 암호가 필요한 경우 제한을 활성화하기 전에 사용자에게 2-4 개의 지연되지 않은 암호 시도를 제공 할 수 있습니다.

이러한 최종 로그인 제한 체계를 공격하는 DoS는 매우 비현실적입니다. 마지막으로, 항상 지속적인 (쿠키) 로그인 (및 / 또는 CAPTCHA 인증 로그인 양식)을 통과하도록 허용 하여 공격이 진행되는 동안 합법적 인 사용자가 지연되지 않도록합니다. 이렇게하면 매우 비실용적 인 DoS 공격이 매우 비실용적 인 공격이됩니다.

또한 관리자 계정은 가장 매력적인 진입 점이므로보다 적극적인 조절을 수행하는 것이 좋습니다.

제쳐두고, 고급 공격자들은 '활동을 확산'하여 로그인 제한을 피하려고합니다.

• IP 주소 플래그 지정을 방지하기 위해 봇넷에 대한 시도 배포
• 한 명의 사용자를 선택하고 50.000 개의 가장 일반적인 암호를 시도하는 대신 (우리의 제한으로 인해 불가능) 가장 일반적인 암호를 선택하여 대신 50.000 명의 사용자에 대해 시도합니다. 이렇게하면 CAPTCHA 및 로그인 제한과 같은 최대 시도 측정을 피할 수있을뿐만 아니라 가장 일반적인 1 번 암호가 49.995 번보다 훨씬 더 많기 때문에 성공 가능성도 높아집니다.
• 각 사용자 계정에 대한 로그인 요청 간격 (예 : 30 초 간격)

 

여기서 가장 좋은 방법은 시스템 전체에서 실패한 로그인 수를 기록하고 사이트의 불량 로그인 빈도의 실행 평균을 기준으로 모든 사용자에게 부과하는 상한선을 사용하는 것입니다.

너무 추상적인가요? 다시 말하겠습니다.

지난 3 개월 동안 귀하의 사이트에 하루 평균 120 회의 불량 로그인이 발생했다고 가정 해 보겠습니다. 이를 사용하여 (실행 평균) 시스템은 글로벌 제한을 3 배로 설정할 수 있습니다. 24 시간 동안 360 번 실패했습니다. 그런 다음 모든 계정에서 실패한 총 시도 횟수가 하루 내에 해당 횟수를 초과하는 경우 (또는 더 나은 방법으로 가속 속도를 모니터링하고 계산 된 임계 값에서 트리거) 시스템 전체 로그인 제한을 활성화하여 모든 사용자에게 짧은 지연을 의미합니다. (쿠키 로그인 및 / 또는 백업 CAPTCHA 로그인을 제외하고 여전히).

또한 분산 된 무차별 대입 공격을 막기 위해 까다로운 핏팔을 피하는 방법에 대한 자세한 내용과 정말 좋은 토론이 포함 된 질문을 게시했습니다.

익스플로잇, 암호를 기록하고 분실 한 경우, 키가있는 랩톱을 도난 당하거나 사용자가 피싱 사이트에 로그인 한 경우 자격 증명이 손상 될 수 있습니다. 로그인은 전화 통화, SMS 메시지, 앱 또는 동글에서받은 일회용 코드와 같은 대역 외 요소를 사용하는 2 단계 인증으로 추가로 보호 할 수 있습니다. 여러 공급자가 2 단계 인증 서비스를 제공합니다.

인증은 다른 공급자가 자격 증명 수집을 처리하는 싱글 사인온 서비스에 완전히 위임 될 수 있습니다. 이것은 문제를 신뢰할 수있는 제 3 자에게 전달합니다. Google과 Twitter는 모두 표준 기반 SSO 서비스를 제공하는 반면 Facebook은 유사한 독점 솔루션을 제공합니다.

출처 : https://stackoverflow.com/questions/549/the-definitive-guide-to-form-based-website-authentication