security - 헤더 - 웹사이트에서 hsts를 사용하므로




양식 기반 웹 사이트 인증에 대한 결정적인 가이드 (8)

결정적인 기사

자격 증명 보내기

자격 증명을 100 % 안전하게 전송하는 유일한 실제 방법은 SSL 을 사용하는 것입니다. JavaScript를 사용하여 비밀번호를 해시하는 것은 안전하지 않습니다. 클라이언트 측 비밀번호 해싱의 일반적인 함정 :

  • 클라이언트와 서버 간의 연결이 암호화되지 않은 경우 수행하는 모든 작업이 MITM (Man-in-the-Middle) 공격에 취약 합니다. 공격자는 들어오는 자바 스크립트를 교체하여 해시를 중단하거나 모든 자격 증명을 서버로 보낼 수 있으며, 클라이언트 응답을 듣고 사용자를 완벽하게 가장 할 수 있습니다. 등 신뢰할 수있는 인증 기관이있는 SSL은 MitM 공격을 방지하도록 설계되었습니다.
  • 서버에서 추가로 중복 작업을 수행하지 않으면 서버에서받은 해시 된 암호의 보안 수준 떨어 집니다.

SRP 라는 또 다른 안전한 방법이 있지만 특허를 받았지만 ( 무료로 라이센스 부여 되었지만) 유용한 구현은 거의 없습니다.

비밀번호 저장

데이터베이스에 암호를 일반 텍스트로 저장하지 마십시오. 자신의 사이트 보안에 관심이없는 경우에도 마찬가지입니다. 일부 사용자가 온라인 은행 계좌의 비밀번호를 재사용한다고 가정하십시오. 따라서 해시 된 비밀번호를 저장하고 원본을 버립니다. 또한 액세스 로그 또는 응용 프로그램 로그에 비밀번호가 표시되지 않아야합니다. OWASP는 새로운 애플리케이션을위한 첫 번째 선택 으로 Argon2 사용할 것을 권장합니다 . 이것이 가능하지 않은 경우, 대신 PBKDF2 또는 scrypt를 사용해야합니다. 마지막으로 위의 사항 중 어느 것도 사용할 수 없으면 bcrypt를 사용하십시오.

해시 자체도 안전하지 않습니다. 예를 들어, 동일한 암호는 동일한 해시를 의미하므로 해시 조회 테이블은 많은 암호를 한 번에 크래킹하는 효과적인 방법입니다. 대신 소금에 절인 해시를 저장하십시오. 솔트는 해싱하기 전에 비밀번호에 추가되는 문자열입니다. 사용자마다 다른 (임의의) 솔트를 사용하십시오. 솔트는 공개 값이므로 해시와 함께 데이터베이스에 저장할 수 있습니다. 이에 대한 자세한 내용은 here 를 참조 here .

즉, 해시 만 있기 때문에 잊어 버린 암호를 사용자에게 보낼 수 없습니다. 사용자를 인증하지 않은 경우 사용자의 비밀번호를 재설정하지 마십시오 (사용자는 저장된 (확인 ​​된) 이메일 주소로 전송 된 이메일을 읽을 수 있음을 증명해야합니다.)

보안 질문

보안 질문은 안전하지 않으므로 사용하지 마십시오. 왜? 보안 질문이 무엇이든 암호가 더 좋습니다. 이 위키에서 Part III : @Jens Roland의 비밀 질문 사용하기를 읽으십시오.

세션 쿠키

사용자가 로그인 한 후 서버는 사용자에게 세션 쿠키를 보냅니다. 서버는 쿠키에서 사용자 이름 또는 ID를 검색 할 수 있지만, 아무도 쿠키를 생성 할 수 없습니다 (TODO Explain 메커니즘).

쿠키는 도용 될 수 있습니다. 쿠키는 클라이언트의 다른 시스템 및 기타 통신만큼 안전합니다. 디스크에서 읽을 수 있고 네트워크 트래픽이 스니핑되고 사이트 간 스크립팅 공격에 의해 제거되고 독이있는 DNS에서 피싱되어 클라이언트가 쿠키를 잘못된 서버로 보냅니다. 영구 쿠키를 보내지 마십시오. 쿠키는 클라이언트 세션이 끝날 때 만료됩니다 (브라우저가 닫히거나 도메인을 떠남).

사용자를 자동 로그인하려면 영구 쿠키를 설정할 수 있지만 전체 세션 쿠키와는 구별되어야합니다. 사용자가 자동 ​​로그인했으며 민감한 작업을 위해 실제로 로그인해야하는 추가 플래그를 설정할 수 있습니다. 이는 완벽하고 개인화 된 쇼핑 경험을 제공하지만 여전히 재무 정보를 보호하려는 쇼핑 사이트에서 인기가 있습니다. 예를 들어, 아마존 방문으로 돌아 가면 로그인 한 것처럼 보이는 페이지가 표시되지만 주문을하려고 할 때 (또는 배송 주소, 신용 카드 등 변경) 확인 요청을합니다. 너의 비밀번호.

반면 은행 및 신용 카드와 같은 금융 웹 사이트는 중요한 데이터 만 가지고 있으며 자동 로그인 또는 보안 수준이 낮은 모드를 허용해서는 안됩니다.

외부 자원 목록

웹 사이트를위한 폼 기반 인증

스택 오버플로는 매우 구체적인 기술적 인 질문에 대한 리소스 일뿐만 아니라 일반적인 문제의 변형을 해결하는 방법에 대한 일반적인 지침이되어야한다고 생각합니다. 이러한 실험에서는 "웹 사이트의 양식 기반 인증"이 좋은 주제가되어야합니다.

다음과 같은 주제를 포함해야합니다.

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

다음과 같은 것들을 포함해서는 안됩니다 :

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

우리를 도와주세요 :

  1. 하위 주제 제안
  2. 이 주제에 관한 좋은 기사 제출
  3. 공식 답변 수정

1 부 : 로그인 방법

인증을 위해 서버 측 스크립트에 값을 POST하는 로그인 + 비밀번호 HTML 양식을 작성하는 방법을 이미 알고 있다고 가정합니다. 아래 섹션에서는 실질적인 인증 방법과 가장 일반적인 보안 위험을 피하는 방법에 대해 설명합니다.

HTTPS로 또는 HTTPS로?

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

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

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

(자신의 롤업) JavaScript 암호화 / 해싱

웹 사이트에서 SSL 인증서를 설정하는 데 인식 된 (지금은 avoidable 있지만) 비용과 기술적 어려움을 고려할 때 일부 개발자는 보안되지 않은 회선을 통해 일반 텍스트 로그인을 전달하지 않기 위해 자체 브라우저 내 해싱 또는 암호화 체계를 롤업하려는 유혹을받습니다.

이것은 고귀한 생각이지만, 위의 방법 중 하나와 결합되지 않는 한, 즉 강력한 암호화로 회선을 확보하거나 검증 된 챌린지 응답을 사용하지 않으면 본질적으로 쓸모가 없으며 보안 결함이 될 수 있습니다. 매커니즘 (무엇이 무엇인지 모른다면, 그것이 입증하기가 가장 어렵고, 설계하기가 어렵고, 디지털 보안에서 개념을 구현하기가 가장 어렵다는 것을 알면됩니다).

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

인류에 대한 보안 문자

CAPTCHA 는 한 가지 특정 범주의 공격, 즉 작업자가없는 자동화 된 사전 / 무차별 시행 착오를 막기위한 것입니다. 이것이 실제 위협이라는 것은 의심의 여지가 없지만 CAPTCHA, 특히 올바르게 설계된 서버 측 로그인 조절 체계가 필요하지 않은 문제를 완벽하게 처리하는 방법이 있습니다. 나중에 논의 할 것입니다.

보안 문자 구현은 동일하게 작성되지 않습니다. 그들은 종종 인간이 해결할 수 없으며 대부분은 실제로 봇에 대해 비효율적이며, 모두 저렴한 3 차 노동 ( OWASP 에 따르면 현재 땀받이 비율은 500 테스트 당 $ 12)에 대해 비효율적이며 일부 구현은 일부 국가에서는 기술적으로 불법입니다 ( OWASP 인증 치트 시트 참조). 보안 문자를 사용해야하는 경우 Google의 reCAPTCHA 사용하십시오. Google reCAPTCHA 는 정의상 OCR이 어렵 기 때문에 (이미 OCR에서 분류 된 책 스캔을 사용하기 때문에) 사용자 친화적 인 시도가 매우 어렵습니다.

개인적으로, 나는 보안 문자를 성가 시게하는 경향이 있으며, 사용자가 여러 번 로그인하지 못하고 조절 지연이 최대가 될 때 마지막 수단으로 만 사용합니다. 이는 수용 할 수 없을 정도로 거의 발생하지 않으며 시스템 전체를 강화합니다.

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

최근에 우리가 많이 본 해킹과 사용자 데이터 유출 이후에 이것은 일반적인 지식이 될 수 있지만, 데이터베이스에 암호를 일반 텍스트로 저장하지 마십시오. 사용자 데이터베이스는 SQL 주입을 통해 일상적으로 해킹, 유출 또는 수집되며, 원시 텍스트 암호를 저장하는 경우 로그인 보안을위한 즉각적인 게임 오버입니다.

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

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

사용자가 선택한 암호가 충분히 강력하지 않아서 (일반적으로 충분한 엔트로피를 포함하지 않음) 암호 추측 공격이 해시에 액세스 할 수있는 공격자가 비교적 짧은 시간 안에 완료 될 수 있으므로 암호 해시에 암호 해시를 사용해서는 안됩니다. 이것이 바로 KDF가 사용되는 이유입니다. 이는 효과적으로 "키를 잡아 당김 "입니다 . 이는 공격자가 만드는 모든 암호 추측으로 인해 해시 알고리즘이 여러 번 반복되는 경우 (예 : 10,000 번) 공격자가 암호를 10,000 번 느리게 추측합니다.

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

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

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

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

파트 II : 로그인 상태를 유지하는 방법-악명 높은 "기억하기"확인란

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

개인적으로, 나는 정기적으로 방문하는 웹 사이트에 대한 지속적인 로그인을 좋아하지만 안전하게 처리하는 방법을 알고 있습니다. 사용자가 동일한 정보를 알고 있다고 확신하는 경우, 양심을 유지하면서 지속적인 로그인을 사용할 수 있습니다. 그렇지 않다면, 로그인 자격 증명을 부주의하게 사용하는 사용자가 해킹 당했을 때 스스로를 가져 왔다는 철학에 가입 할 수 있습니다. 그것은 우리가 사용자의 집에 가서 모니터 가장자리에 줄을 지어 암호가있는 얼굴을 유발하는 Post-It 노트를 모두 찢어 버리는 것과는 다릅니다.

물론 일부 시스템 에서는 계정을 해킹 할 여유가 없습니다 . 이러한 시스템의 경우 지속적인 로그인이 필요하다는 것을 정당화 할 수있는 방법이 없습니다.

영구 로그인 쿠키를 구현하기로 결정한 경우 다음과 같이하십시오.

  1. 먼저, 주제에 관한 Paragon Initiative의 기사 를 읽으십시오. 많은 요소를 올바르게 가져와야하며 기사는 각 요소를 설명하는 데 도움이됩니다.

  2. 가장 일반적인 함정 중 하나를 되풀이하려면 영구 로그인 쿠키 (TOKEN)를 데이터베이스에 저장하지 마십시오. 로그인 토큰은 Password Equivalent이므로 공격자가 데이터베이스에 손을 대면 마치 일반 텍스트 로그인-암호 조합 인 것처럼 토큰을 사용하여 모든 계정에 로그인 할 수 있습니다. 따라서 영구 로그인 토큰을 저장할 때 해싱을 사용하십시오 ( https://security.stackexchange.com/a/63438/5002 에 따르면 약한 해시는이 목적에 적합합니다).

파트 III : 비밀 질문 사용

'비밀 질문'을 구현하지 마십시오 . '비밀 질문'기능은 보안 안티 패턴입니다. 링크 번호 4의 필독서를 반드시 읽어야합니다. Sarah Palin에게 Yahoo! 그녀의 보안 질문에 대한 대답은 : "Wasilla High School"이었기 때문에 이전 대통령 선거 기간 동안 이메일 계정이 해킹당했습니다!

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

  • 어머니의 성함 또는 좋아하는 애완 동물과 같은 '표준'비밀 질문

  • 누구나 자신의 블로그, 링크드 인 프로필 등에서 들어 올릴 수있는 간단한 퀴즈

  • 비밀번호를 추측하는 것보다 대답하기 쉬운 질문이 있습니다. 어느 암호에 대해서도 상상할 수있는 모든 질문이 있습니다.

결론적으로 보안 질문은 사실상 모든 형태와 변형에서 안전하지 않으므로 어떠한 이유로 든 인증 체계에 사용해서는 안됩니다.

보안 문제가 생겨난 진정한 이유는 전자 메일에 액세스하여 재 활성화 코드에 액세스 할 수없는 사용자의 몇 가지 지원 요청 비용을 편리하게 절약 할 수 있기 때문입니다. 이것은 보안과 Sarah Palin의 명성을 희생시킵니다. 그럴 가치가 있습니까? 아마 아닙니다.

IV 부 : 잊어 버린 암호 기능

잊어 버린 / 분실 된 사용자 암호를 처리 하기 위해 보안 질문 사용 해서는 안되는 이유를 이미 언급했습니다. 또한 사용자에게 실제 비밀번호를 이메일로 보내면 안된다는 것은 말할 것도 없습니다. 이 분야에서는 피해야 할 함정이 두 개 이상 있습니다.

  1. 잊어 버린 암호를 자동 생성 된 강력한 암호로 재설정 하지 마십시오. 이러한 암호는 기억하기 어렵 기 때문에 사용자가 암호를 변경하거나 기록해야합니다 (예 : 모니터 가장자리의 밝은 노란색 포스트잇). 새로운 비밀번호를 설정하는 대신 사용자가 새로운 비밀번호를 바로 선택할 수있게합니다. (일반적으로 사용자가 암호 관리자를 사용하여 암호를 쓰지 않고 기억하기 어려운 암호를 저장 / 관리하는 경우)는 예외입니다.

  2. 항상 데이터베이스에서 유실 된 비밀번호 코드 / 토큰을 해시하십시오. 또한 이 코드는 Password Equivalent의 또 다른 예이므로 공격자가 데이터베이스에 손을 넣은 경우 반드시 해시해야합니다. 분실 한 비밀번호 코드가 요청되면 일반 텍스트 코드를 사용자의 이메일 주소로 보낸 다음 해시하고 데이터베이스에 해시를 저장 하고 원본을 버립니다 . 비밀번호 나 영구 로그인 토큰과 같습니다.

마지막 참고 사항 : 항상 '비밀번호 암호'를 입력하기위한 인터페이스가 최소한 로그인 양식 자체보다 안전해야합니다. 그렇지 않으면 공격자 가이 정보를 사용하여 대신 액세스 할 수 있습니다. 매우 긴 '비밀번호 암호'(예 : 대소 문자를 구분하는 16 자의 영숫자)를 생성하는 것이 좋은 시작이지만 로그인 양식 자체와 동일한 제한 체계를 추가하는 것이 좋습니다.

파트 V : 비밀번호 강도 확인

먼저, 현실 점검을 위해이 작은 기사를 읽으십시오 : 500 개의 가장 일반적인 암호

아마도이 목록은 어느 시스템 에서나 가장 일반적인 암호의 정식 목록이 아닐 수도 있지만, 시행되는 정책이 없을 때 사람들이 암호를 얼마나 잘 선택하지 않는지를 나타내는 좋은 증거 일 것입니다. 또한 최근에 도난당한 암호를 공개적으로 사용 가능한 분석과 비교하면 목록이 집과 매우 흡사하게 보입니다.

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

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

엔트로피 암호의 사용자 친 화성을 상쾌하게하려면 Randall Munroe의 Password Strength xkcd 를 적극 권장합니다.

Troy Hunt 's I Been Pwned API 사용 하여 공개 데이터 유출로 인해 손상된 비밀번호와 비교하여 사용자 비밀번호를 확인합니다.

6 부 : 훨씬 더-또는 : 빠른 실행 로그인 시도 방지

먼저, 숫자를 살펴보십시오 : 비밀번호 복구 속도-비밀번호가 얼마나 오래 지속됩니까?

해당 링크의 테이블을 살펴볼 시간이 없다면 다음 목록이 있습니다.

  1. 주판으로 해독하더라도 약한 암호를 해독하는 데 거의 시간 이 걸리지 않습니다.

  2. 대소 문자를 구분하지 않으면 영숫자 9 자 암호를 해독하는 데 거의 시간 이 걸리지 않습니다

  3. 암호 가 8 자 미만인 경우 복잡한 기호 및 문자, 숫자, 대소 문자 암호를 해독하는 데 거의 시간 이 걸리지 않습니다 (데스크탑 PC는 문제에서 최대 7 자까지 전체 키 공간을 검색 할 수 있음) 며칠 또는 몇 시간)

  4. 그러나 초당 1 회 시도로 제한되는 경우 6 자 암호조차 해독하는 데 시간이 많이 걸립니다 !

그렇다면이 숫자들로부터 무엇을 배울 수 있습니까? 글쎄요, 그러나 우리는 가장 중요한 부분에 집중할 수 있습니다. 많은 수의 신속한 연속 로그인 시도 (예 : 무차별 대입 공격)를 방지하는 것이 그렇게 어렵지 않다는 사실. 그러나 올바르게 방지하는 것은 쉬운 일이 아닙니다.

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

  • N 번의 시도가 실패한 후 보안 문자를 제시하십시오 (지루하고 짜증나지만 종종 반복됩니다)

  • 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 공격은 매우 실용적이지 않습니다.

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

제 7 부 : 분산 된 무차별 대입 공격

더 나아가, 고급 공격자들은 '활동 확산'을 통해 로그인 제한을 피하려고 시도합니다.

  • IP 주소 플래그를 방지하기 위해 봇넷에 시도 배포

  • 한 명의 사용자를 선택하고 55,000 개의 가장 일반적인 비밀번호 (스로틀 링으로 인해 사용할 수없는)를 시도하는 대신 가장 일반적인 비밀번호를 선택하고 대신 50.000 명의 사용자에 대해 시도합니다. 이렇게하면 보안 문자 및 로그인 조절과 같은 최대 시도 횟수를 극복 할 수있을뿐만 아니라 가장 일반적인 암호가 49.995보다 훨씬 많기 때문에 성공 가능성도 높아집니다.

  • 각 사용자 계정에 대한 로그인 요청 간격 (예 : 30 초 간격)

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

너무 추상? 다시 말해서 :

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

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

파트 VIII : 2 단계 인증 및 인증 제공자

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

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

웹 인증에 대한 필수 링크

  1. OWASP 인증 가이드 / OWASP 인증 치트 시트
  2. 웹에서 클라이언트 인증의 수행 및 금지 (읽기 쉬운 MIT 연구 논문)
  3. 위키 백과 : HTTP 쿠키
  4. 대체 인증에 대한 개인 지식 질문 : Facebook 시대의 보안 질문 (매우 읽기 쉬운 Berkeley 연구 논문)

매우 중요한 의견 하나를 추가하고 싶습니다 :-

  • " 기업의 인트라넷 환경에서"대부분의 경우 전술 한 내용이 모두 적용되지 않을 수도 있습니다!

많은 회사에서 URL을 통해 구현 된 "기업 응용 프로그램"인 "내부 전용"웹 사이트를 배포합니다. 이 URL은 "회사 내부 네트워크"내에서만 해결할 수 있습니다 (아마도 ...) . (VPN에 연결된 모든 '도로 전사'를 마술로 포함하는 네트워크는 무엇입니까?)

사용자가 상술 한 네트워크에 정식으로 연결되면, 그들의 신원 ( "인증") " 이미 확정 된"이고, 어떤 것들을 할 수 있는 그들의 허가 ( "권한") 는 ...와 같은 것이다. .. "이 웹 사이트에 액세스합니다."

이 "인증 + 권한 부여"서비스는 LDAP (Microsoft OpenDirectory) 또는 Kerberos 와 같은 여러 가지 다른 기술로 제공 될 수 있습니다 .

당신의 관점에서, 당신은 단순히 이것을 알고 있습니다. 당신 의 웹 사이트에 합법적으로 바람을 피우는 사람 은 [토론 적으로 ...를 포함하는 환경 변수]를 동반 해야한다는 것입니다. ( , 그러한 토큰이 없으면 즉시 근거가되어야합니다 404 Not Found .)

토큰의 가치는 당신에게 이해가되지 않지만, 필요하다면, "적절한 수단이 존재"하여 귀하의 웹 사이트가 "[정식 적으로"아는 사람 (LDAP ... 등)에게 모든 것에 대해 요청할 수 있습니다 (!) 당신이 가질 수있는 질문. 다시 말해, 당신 은 어떤 "가정용 논리"를 쓸모 가 없습니다 . 대신에, 당신은 당국에 문의하고 암묵적으로 그 평결을 믿습니다.

어 ... 그건 로부터 정신 스위치 "울리 야생 앤 인터넷."


방금 잘 작동하는 것으로 밝혀진이 솔루션을 공유한다고 생각했습니다.

나는 그것을 더미 필드 라고 부릅니다 (그러나 나는 이것을 발명하지 않았기 때문에 저를 신용하지 마십시오).

한마디로 : 당신은 이것을 당신의 것으로 삽입 <form> 하고 유효성을 검사 할 때 비어 있는지 확인해야합니다.

<input type="text" name="email" style="display:none" />

트릭은 필수 필드에 데이터를 삽입해야한다고 봇을 속이는 것입니다. 이것이 바로 입력 이름을 "이메일"이라고하는 이유입니다. 사용중인 이메일이라는 필드가 이미있는 경우 더미 필드의 이름을 "company", "phone"또는 "emailaddress"와 같은 다른 이름으로 지정해야합니다. 필요하지 않은 것을 선택하고 사람들이 일반적으로 웹 양식을 작성하기 위해 논리적으로 생각하는 것과 같은 소리를 선택하십시오. 이제 input CSS 또는 JavaScript / jQuery를 사용 하여 필드를 숨기십시오 -가장 적합한 것이 무엇이든간에 입력 을 설정 하지 마십시오. 그렇지 않으면 봇이 그에 빠지지 않습니다. type hidden

클라이언트 또는 서버 측에서 양식의 유효성을 검사 할 때 더미 필드가 채워 졌는지 확인하여 사람 또는 봇이 보낸 것인지 확인하십시오.

예:

사람의 경우 : 사용자는 더미 필드 (내 경우에는 "이메일"이라고 함)를 보지 않고 채우려 고 시도하지 않습니다. 따라서 양식을 보낼 때 더미 필드의 값은 여전히 ​​비어 있어야합니다.

봇의 경우 : 봇은 유형이있는 필드 text 와 이름 email (또는 사용자가 불렀던 이름)을보고 논리적으로 적절한 데이터로 채우려 고 시도합니다. 멋진 CSS로 입력 양식의 스타일을 지정해도 상관 없으며 웹 개발자는 항상 그렇게합니다. 더미 필드의 값이 무엇이든 0 문자 보다 큰 경우에는 신경 쓰지 않습니다 .

이 방법을 방명록과 함께 CAPTCHA 와 함께 사용 했는데 그 이후로 단일 스팸 게시물을 보지 못했습니다. 전에는 보안 문자 전용 솔루션을 사용했지만 결국에는 매시간 약 5 개의 스팸 게시물이 발생했습니다. 양식에 더미 필드를 추가하면 모든 스팸이 (최소한 지금까지) 중지되었습니다.

나는 이것이 로그인 / 인증 양식으로도 잘 사용될 수 있다고 생각합니다.

경고 : 물론이 방법은 100 % 완전하지 않습니다. 스타일을 display:none 적용한 입력 필드를 무시하도록 봇을 프로그래밍 할 수 있습니다 . 또한 모든 양식 필드를 자동으로 채우려면 특정 양식의 자동 완성 기능을 사용하는 사람들 (대부분의 브라우저에 내장되어 있음)을 고려해야합니다. 그들은 더미 필드를 선택할 수도 있습니다.

더미 필드를 표시하지만 화면 경계 외부에두면이 값을 약간 변경할 수 있지만 이는 전적으로 사용자에게 달려 있습니다.

창의력을 발휘하십시오!


위의 답변이 "틀린 것"이라고 생각하지는 않지만 다루지 않는 넓은 범위의 인증이 있습니다 (또는 "쿠키 세션을 구현하는 방법", "사용 가능한 옵션 및 거래는 무엇입니까"에 중점을 둡니다. -오프 ".

내가 제안한 수정 / 답변은

  • 문제는 비밀번호 확인보다 계정 설정에 더 있습니다.
  • 2 단계 인증의 사용은보다 영리한 암호 암호화 수단보다 훨씬 안전합니다.
  • 계정을 만들 때 자체적으로 생성 된 데이터가 가치가없고 자체적으로 생성되지 않은 경우 (즉, Facebook, Flickr 와 같은 웹 2.0 스타일)가 아니면 사용자 고유의 로그인 양식 또는 비밀번호 데이터베이스 저장소를 구현하려고 시도하지 마십시오 .

    1. 다이제스트 인증은 모든 주요 브라우저와 서버에서 지원되는 표준 기반 접근 방식으로, 보안 채널을 통해서도 암호를 보내지 않습니다.

이렇게하면 브라우저 자체가 매번 통신을 다시 암호화하므로 "세션"또는 쿠키가 필요하지 않습니다. 가장 "가벼운"개발 방식입니다.

그러나 저렴한 공개 서비스를 제외하고는 이것을 권장하지 않습니다. 이것은 위의 다른 답변 중 일부와 관련된 문제입니다. 서버 측 인증 메커니즘을 다시 구현하지 마십시오.이 문제는 대부분의 주요 브라우저에서 해결되었으며 지원됩니다. 쿠키를 사용하지 마십시오. 직접 제작 한 데이터베이스에는 아무 것도 저장하지 마십시오. 요청이 인증되면 요청마다 요청하십시오. 다른 모든 구성 및 타사의 신뢰할 수있는 소프트웨어가 지원해야합니다.

그래서 ...

먼저, 초기 비밀번호 생성과 비밀번호 재확인을 혼동하고 있습니다. Flickr이고 처음으로 사이트를 만드는 경우 새 사용자는 0 값 (빈 웹 공간)에 액세스 할 수 있습니다. 계정을 만드는 사람이 자신의 이름에 대해 거짓말하고 있는지는 상관하지 않습니다. 내가 병원 인트라넷 / 엑스트라 넷의 계정을 생성하고 있다면, 모든 의료 기록의 가치 거짓말, 나는 그렇게 계정 작성자의 신원 (*)에 대해주의를.

이것은 매우 어려운 부분입니다. 괜찮은 해결책은 신뢰의 웹입니다. 예를 들어, 의사로서 병원에 가입합니다. 사진, 여권 번호 및 공개 키로 어딘가에 호스팅 된 웹 페이지를 만들고 개인 키로 모두 해시합니다. 그런 다음 병원을 방문하면 시스템 관리자가 여권을보고 사진이 자신과 일치하는지 확인한 다음 병원 개인 키로 웹 페이지 / 사진 해시를 해시합니다. 이제부터 키와 토큰을 안전하게 교환 할 수 있습니다. 병원을 신뢰하는 사람은 누구나 할 수 있습니다 (비밀 소스 BTW가 있습니다). 시스템 관리자는 RSA 동글 또는 기타 2 단계 인증을 제공 할 수도 있습니다 .

그러나 이것은 많은 번거 로움이며 웹 2.0은 아닙니다. 그러나 자체 생성되지 않은 중요한 정보에 액세스 할 수있는 새 계정을 만드는 유일한 방법입니다.

  1. 신뢰할 수있는 타사와의 싱글 사인온 메커니즘 인 Kerberos 및 SPNEGO는 기본적으로 사용자가 신뢰할 수있는 타사에 대해 확인합니다. (NB는 OAuth 신뢰하지 않아야합니다. )

  2. SRP 신뢰할 수있는 제 3자가없는 일종의 영리한 비밀번호 인증. 그러나 여기서는 "비싸더라도 이중 인증을 사용하는 것이 더 안전합니다"라는 영역으로 들어가고 있습니다.

  3. SSL 클라이언트 측-클라이언트에 공개 키 인증서를 제공합니다 (모든 주요 브라우저에서 지원되지만 클라이언트 시스템 보안에 대한 의문을 제기 함).

결국, 보안 위반 비용과보다 안전한 접근 방식을 구현하는 비용은 트레이드 오프입니다. 언젠가, 우리는 적절한 PKI 널리 수용되어 더 이상 자체적으로 롤링 된 인증 양식 및 데이터베이스를 볼 수없는 것을 볼 수 있습니다. 어느 날 ...


인증 시스템과 관련하여 내가 가장 좋아하는 규칙은 암호가 아닌 암호를 사용하는 것입니다. 기억하기 쉽고 깨지기 어렵다. 추가 정보 : 코딩 공포 : 암호와 암호 문구


해싱시 MD5와 같은 빠른 해시 알고리즘을 사용하지 마십시오 (많은 하드웨어 구현이 존재 함). SHA-512와 같은 것을 사용하십시오. 암호의 경우 해시가 느릴수록 좋습니다.

해시를 더 빨리 만들수록 모든 무차별 검사기가 더 빨리 작동 할 수 있습니다. 따라서 해시가 느리면 무차별 강제 실행 속도가 느려집니다. 느린 해시 알고리즘은 더 긴 암호 (8 자리 +)에 대해 무차별 강제 실행을 불가능하게합니다.






article