폼을 기반으로 한 웹사이트 인증에 대한 궁극적인 가이드 [종료됨]

닫혔습니다. 이 질문은 더욱 focused 한 내용이 필요합니다. 현재 답변을 받지 않고 있습니다.

6년 전에 닫혔습니다.

커뮤니티는 1년 전에 이 질문을 다시 열까에 대해 검토했으며 닫혔습니다.

원래 종료 이유가 해결되지 않았습니다.

이 질문의 답변들은 community effort입니다. 기존 답변을 편집하여 이 포스트를 개선하십시오. 새로운 답변이나 상호 작용을 현재 받지 않습니다.

Moderator 주의:

이 질문은 현재 Stack Overflow에서 적용되는 topicality rules 포맷과는 맞지 않습니다. 이러한 경우 역사적인 잠금을 일반적으로 사용하여 내용이 여전히 가치 있는 경우에 대응합니다. 그러나이 질문에 대한 답변은 활발하게 유지되고 있으며 역사적인 잠금은 답변 수정을 허용하지 않습니다. 따라서 위키 답변 잠금이 적용되어 답변을 편집할 수 있습니다. 이 질문이 Stack Overflow의 적절한 질문 예제가 아닌 경우가 있습니다.

웹 사이트를 위한 양식 기반 인증

우리는 스택 오버플로(Stack Overflow)가 매우 구체적인 기술 질문뿐만 아니라 일반적인 문제의 변형에 대한 해결 방법에 대한 일반 지침을 제공하는 자원이 되어야 한다고 믿습니다. 웹 사이트용 양식 기반 인증은 이러한 실험에 적합한 주제가 될 것입니다.

주제로는 다음과 같은 것이 포함되어야 합니다:

로그인하는 방법

로그아웃하는 방법

로그인 상태 유지하는 방법

쿠키 관리 (권장 설정 포함)

SSL/HTTPS 암호화

암호를 저장하는 방법

비밀 질문을 사용하여

잊어버린 사용자 이름/비밀번호 기능

nonces 사용하여 cross-site request forgeries (CSRF) 방지하기

OpenID

나를 기억해주세요 체크박스

브라우저 자동완성 기능으로 사용자 이름과 비밀번호를 작성합니다.

비밀 URL들 (공개 URL)는 다이제스트로 보호됩니다.

비밀번호 강도 확인하기

이메일 유효성 검사

그리고 form based authentication에 대한 더 많은 정보가 있습니다...

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

역할과 권한

HTTP 기본 인증

우리를 도와주세요:

하위 주제 제안하기

이 주제에 대해 좋은 기사를 제출하기

공식 답변 편집하기

답변 1

일부: 로그인하는 방법

당신이 이미 서버 측 인증을 위해 값이 게시되는 로그인 + 비밀번호 HTML 양식을 작성하는 방법을 알고 있다고 가정합니다. 아래 섹션에서는 안전하고 실용적인 인증 패턴과 가장 일반적인 보안 위험을 피하는 방법에 대해 다룰 것입니다.

HTTPS를 사용할 것인가 말 것인가?

연결이 이미 안전하게 (즉, SSL/TLS를 사용하여 HTTPS를 통해 터널링되었을 경우) 수행된 경우 로그인 양식 값은 평문으로 전송됩니다. 이는 브라우저와 웹 서버 간의 라인에서 도청하는 누구나 로그인을 읽을 수 있게합니다. 이러한 유형의 도청은 일반적으로 정부에서 수행하지만, 일반적으로 우리는 '소유'된 전선에 대해 다루지 않겠습니다. 이를 위해 HTTPS를 사용하십시오.

본질적으로 로그인 중에 도청 / 패킷 스니핑을 방지하는 유일한 실용적인 방법은 HTTPS 또는 기타 인증 기반 암호화 스키마 (예 : #$^ $ ^& $ & $) 또는 입증 된 도전-응답 스키마 (예 :Diffie-Hellman 기반 SRP)를 사용하는 것입니다. 다른 방법은 도청하는 공격자에게 쉽게 우회 될 수 있습니다.

물론 조금 불편하더라도, 구글 인증 앱, 물리적인 '콜드 워 스타일' 코드북 또는 RSA 키 생성 동글과 같은 형태의 이중 인증 체계를 적용할 수도 있습니다. 올바르게 적용한다면, 미보호 연결에서도 작동할 수 있지만, 개발자가 이중 인증을 구현하되 SSL을 구현하지 않을 것으로 상상하기는 어렵습니다.

자체(로) JavaScript 암호화/해싱 구현하지 마세요.

당신의 웹 사이트에서 SSL 인증서를 설정하는 것으로 인식되는 (하지만 이제는 avoidable ) 비용과 기술적인 어려움 때문에, 일부 개발자는 미보안 상태의 와이어를 통해 암호화되지 않은 로그인 정보를 전송하지 않기 위해 브라우저에서 자체 해싱 또는 암호화 체계를 사용하려는 유혹을 느낍니다.

이것은 고귀한 생각이지만, 암호화를 강화하거나 시험된 챌린지-응답 메커니즘을 사용하는 것과 결합되지 않는 한 (그게 뭔지 모르겠다면, 디지털 보안에서 가장 증명하기 어렵고, 설계하기 어렵고, 구현하기 어려운 개념 중 하나임을 알아두세요) 본질적으로 쓸모 없을 뿐 아니라 욕설이 될 수도 있습니다.

비밀번호를 해싱하는 것은 비밀번호 노출로부터 효과적일 수 있지만, 재전송 공격, 중간자 공격/해킹(공격자가 브라우저까지 도달하기 전에 약간의 바이트를 삽입할 수 있다면 JavaScript에서 해싱을 단순히 주석 처리할 수 있음) 또는 브루트 포스 공격에 취약합니다 (사용자 이름, 소금 및 해싱 된 비밀번호를 모두 공격자에게 제공하기 때문).

인간 대 캡챠스

CAPTCHA는 한 가지 특정한 종류의 공격을 방지하기 위해 만들어졌습니다: 자동사전/억제적인 시행착오를 이용한 시스템 공격입니다. 이러한 공격이 실제로 존재하는 데에는 의심의 여지가 없지만, CAPTCHA 없이도 원활하게 처리할 수 있는 방법이 있습니다. 특히, 적절하게 설계된 서버측 로그인 제한 기능이 있습니다. 추후에 이에 대해 논의하겠습니다.

CAPTCHA 구현이 모두 같은 것은 아님을 알아두세요. 그것들은 종종 사람들이 풀기 어렵지만 대부분은 사실 봇에 대해 효과적이지 않고, 모두가 싼 노동력에 대해 효과적이지 않으며 (현재 노동요금은 500 개의 테스트당 12 달러이다.), 일부 구현은 일부 국가에서 기술적으로 불법일 수도 있습니다 ( OWASP Authentication Cheat Sheet 참조). CAPTCHA를 사용해야 한다면, 이미 OCR-오분류된 책 스캔을 사용하기 때문에 OCR-어려운 (OCR-hard) 기능을 하며 사용자 친화적이기 위해 매우 노력하는 Google의 reCAPTCHA 를 사용하세요.

개인적으로 나는 CAPTCHA를 귀찮게 느끼는 경향이 있으며, 사용자가 여러 번 로그인에 실패하고 서버 대기 시간이 최대치에 도달했을 때만 마지막 수단으로 사용합니다. 이는 받아들일만한 빈도로 발생하며, 전체 시스템을 강화합니다.

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

최근 몇 년간 많은 누설과 사용자 데이터 유출 사건이 일어난 이후에야 드디어 이것이 일반적인 지식이 되었겠지만, 말해야 할 것이 있다: 데이터베이스에서 비밀번호를 평문으로 저장하지 마십시오. 사용자 데이터베이스는 정기적으로 해킹되거나 유출되거나 SQL 주입을 통해 얻어집니다. 만약 평문으로 비밀번호를 저장한다면, 즉시 로그인 보안에 실패할 것입니다.

만약 비밀번호를 저장할 수 없다면 로그인 폼에서 POST 된 로그인 + 비밀번호 조합이 올바른지 어떻게 확인합니까? 답은 key derivation function을 사용한 해싱입니다. 새 사용자가 만들어지거나 비밀번호가 변경될 때마다 패스워드를 가져와 Argon2, bcrypt, scrypt 또는 PBKDF2와 같은 KDF를 통해 암호화하여 correcthorsebatterystaple과 같은 평문 비밀번호를 긴, 랜덤한 문자열로 바꿉니다. 이렇게 함으로써 데이터베이스에 저장하기 훨씬 안전해집니다. 로그인을 확인하려면 입력된 비밀번호에 대해 동일한 해시 함수를 실행하고 이번에는 솔트를 전달하여 결과 해시 문자열을 데이터베이스에 저장된 값과 비교합니다. Argon2, bcrypt 및 scrypt는 이미 해시와 함께 솔트를 저장합니다. 자세한 정보는 sec.stackexchange의 article를 참조하세요.

소금이 사용되는 이유는 자체적인 해싱만으로는 충분하지 않기 때문입니다. 해시를 보호하기 위해 '소금'이라고 불리는 것을 추가하려고합니다. 소금을 추가하면 해시가 rainbow tables에 대한 보호를 받을 수 있습니다. 소금은 두 개의 완전히 일치하는 암호가 동일한 해시 값으로 저장되지 않도록하여 공격자가 암호 추측 공격을 실행할 때 전체 데이터베이스가 한 번에 스캔되는 것을 방지합니다.

사용자가 선택한 비밀번호가 충분히 강력하지 않기 때문에 (즉, 일반적으로 충분한 엔트로피가 포함되어 있지 않음) 암호화 해시는 암호 저장에 사용해서는 안됩니다. 해시에 접근할 수 있는 공격자가 있는 경우 비밀번호 추측 공격이 상대적으로 짧은 시간 안에 완료될 수 있기 때문입니다. 이것이 KDF가 사용되는 이유입니다 - 이러한 것들은 효과적으로 비밀번호 추측 공격시에 해시 알고리즘의 여러 반복을 유발하므로, 예를 들어 10,000번, 공격자가 비밀번호를 추측하는 데 10,000배 느리게 만드는 것입니다.

세션 데이터 - Spiderman69으로 로그인되어 있습니다

서버가 로그인 및 암호를 사용자 데이터베이스와 대조하여 일치를 확인한 후, 시스템은 브라우저가 인증되었음을 기억하는 방법이 필요합니다. 이 사실은 세션 데이터에서 서버 측에만 저장되어야 합니다.

세션 데이터에 익숙하지 않은 경우, 다음과 같이 작동합니다. 만료되는 쿠키에 한 개의 무작위로 생성된 문자열이 저장되고, 이로 인해 서버에 저장된 데이터 컬렉션인 세션 데이터가 참조됩니다. MVC 프레임워크를 사용하는 경우, 이는 이미 처리되었을 것입니다.

가능하다면 브라우저로 보내는 세션 쿠키에는 반드시 안전 및 HttpOnly 플래그가 설정되어 있는지 확인하십시오. HttpOnly 플래그는 XSS 공격을 통해 쿠키가 읽히는 것을 방지하는 일부 보호 기능을 제공합니다. 안전 플래그는 쿠키가 HTTPS를 통해만 다시 전송되도록하므로 네트워크 스니핑 공격으로부터 보호합니다. 쿠키의 값은 예측할 수 없어야 합니다. 존재하지 않는 세션을 참조하는 쿠키가 제시되는 경우 즉시 해당 값이 session fixation를 방지하도록 바꾸어야 합니다.

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

PART II: 로그인 상태 유지 방법 - 유명한 기억하기 체크박스

지속적 로그인 쿠키(나를 기억해 기능)는 위험 지역입니다. 한편, 사용자가 그것들을 다루는 방법을 이해할 때, 전통적인 로그인과 완전히 안전합니다. 또 다른 한편으로는, 공공장소에서 사용하고 로그아웃을 잊을 수있는 부주의한 사용자(브라우저 쿠키가 무엇인지 또는 어떻게 삭제하는지 모르는 경우)의 손에서 거대한 보안 위협이 될 수 있습니다.

개인적으로, 나는 정기적으로 방문하는 웹사이트에서 지속적인 로그인을 좋아하지만, 안전하게 처리하는 방법을 알고 있습니다. 사용자들이 같은 것을 알고 있다면 깨끗한 양심으로 지속적인 로그인을 사용할 수 있습니다. 그렇지 않다면, 사용자들이 로그인 자격 증명에 무신경한 경우 해킹당하면 스스로 가져왔다는 철학을 구독 할 수 있습니다. 모니터 가장자리에 정렬된 비밀번호를 적은 그 모든 어이없는 포스트잇 메모를 사용자들의 집에 가서 찢어내지는 않는다니까요.

물론 일부 시스템은 어떤 계정도 해킹 당할 수 없는 상황이라면 계속된 로그인을 정당화할 수 없습니다.

만약 지속적 로그인 쿠키를 구현하기로 결정한다면, 이렇게 하십시오:

먼저, 주제에 관한 Paragon Initiative's article을(를) 읽는 데 시간을 내세요. 여러 요소들을 제대로 이해해야 하며, 이 기사는 각각을 설명하는 데 큰 역할을 합니다.

그리고 가장 흔한 함정 중 하나를 강조하자면, 로그인 쿠키(토큰)를 데이터베이스에 저장하지 마십시오. 그것의 해시만 저장하십시오! 로그인 토큰은 패스워드와 같은 역할을 하기 때문에 공격자가 데이터베이스를 손에 넣으면 토큰을 이용하여 일반 텍스트 로그인-암호 조합과 마찬가지로 어떤 계정에 로그인 할 수 있습니다. 따라서, 영구적인 로그인 토큰을 저장할 때 해시를 사용하세요. (이를 위해 약한 해시도 충분합니다.)

제 III 부 : 비밀 질문 사용하기

'비밀 질문'은 구현하지 마십시오. '비밀 질문' 기능은 보안 반 패턴입니다. 필수 독서 목록의 링크 번호 4에서 논문을 읽으십시오. 전 대선 캠페인 중 야후! 이메일 계정이 해킹되었을 때 보안 질문의 답이 '위실라 고등학교'였기 때문에 사라 펠린에게 물어볼 수 있습니다!

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

표준 비밀 질문인 어머니의 여성성 성씨나 좋아하는 애완동물.

어떤 사람든 블로그, 링크드인 프로필 또는 유사한 곳에서 가져올 수 있는 간단한 트리비아.

그들의 비밀번호를 추측하기보다 답하기 더 쉬운 질문이 있습니다. 어떤 적절한 비밀번호에 대해서도 상상할 수 있는 모든 질문입니다.

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

보안 질문이 존재하는 진짜 이유는, 이메일에 접근하지 못하는 사용자들이 재활성화 코드를 얻기 위해 지원 전화를 몇 통 걸지 않도록 편리하게 비용을 절감할 수 있다는 것입니다. 이는 보안과 사라 페일린의 평판을 희생하는 대가로 이뤄졌습니다. 그 가치가 있는가? 아마도 그렇지 않습니다.

제4부 : 비밀번호 분실 기능

나는 이미 왜 보안 질문을 사용해서는 안 되는지 잊어버린/분실된 사용자 비밀번호를 처리하는 데 사용해서는 안 된다고 언급했으며, 또한 사용자의 실제 비밀번호를 이메일로 보내서는 안 된다는 것은 말할 필요도 없다. 이 분야에서 피해야 할 적어도 두 가지 더 흔한 함정이 있다.

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

항상 데이터베이스에서 잃어버린 암호 코드/토큰을 해시하여 저장하십시오. 다시 말하면, 이 코드는 암호 등가물의 또 다른 예시이므로 공격자가 데이터베이스를 손에 넣을 경우 해시해야 합니다. 잃어버린 암호 코드가 요청되면 평문 코드를 사용자의 이메일 주소로 보내고, 그런 다음 해시해 데이터베이스에 저장하십시오. 그리고 원래 코드를 버리십시오. 비밀번호나 지속적인 로그인 토큰과 마찬가지입니다.

최종적으로, '잃어버린 비밀번호 코드'를 입력하는 인터페이스가 로그인 양식 그 자체만큼 안전하도록 항상 확인해야하며, 그렇지 않으면 공격자가 액세스를 얻는 데 이러한 것을 사용할 것입니다. 매우 긴 '잃어버린 비밀번호 코드' (예: 16 개의 대문자 및 숫자)를 생성하는 것이 좋은 시작이지만 로그인 양식 그 자체에 대한 쓰로틀링 체계와 동일한 쓰로틀링 체계를 추가하는 것이 좋습니다.

PART V: 암호 안전성 확인하기

먼저, 현실 판단을 위해 이 작은 기사를 읽어보시기 바랍니다: The 500 most common passwords.

좋아요, 아마도 이 목록이 어디에서든 가장 일반적인 비밀번호 목록은 아니겠지만, 강제적인 정책이 없을 때 사람들이 어떻게 비밀번호를 선택하는지를 잘 보여줍니다. 게다가 최근에 유출된 비밀번호를 분석한 결과와 비교하면 이 목록은 당장 내 집안과 너무나도 유사합니다.

그러므로: 최소 비밀번호 강도 요구사항이 없다면, 사용자 중 2%는 상위 20개 가장 일반적인 비밀번호 중 하나를 사용합니다. 이는 곧, 공격자가 단지 20번 시도해도, 여러분의 웹사이트에서 50개의 계정 중 1개가 뚫릴 수 있다는 것을 의미합니다.

이를 방지하기 위해서는 암호의 엔트로피를 계산하고 임계점을 적용해야 합니다. 국립표준기술연구소(NIST)는 매우 좋은 제안서를 제시하고 있습니다. 이를 사전과 키보드 레이아웃 분석과 함께 사용하면 (예: 'qwertyuiop'은 좋지 않은 암호입니다) 18비트 수준의 엔트로피로 보안을 강화할 수 있습니다. 암호 강도를 간단히 계산하고 사용자에게 피드백을 제공하는 것은 좋은 일이지만 충분하지 않습니다. 강제하지 않으면 많은 사용자들은 무시할 가능성이 높습니다.

고엔트로피 비밀번호의 사용자 친화성에 대한 상쾌한 시각을 원한다면, 랜들 먼로의 Password Strength xkcd 을 강력 추천합니다.

트로이 헌트의 Have I Been Pwned API을 활용하여 공개 데이터 침해로 유출된 비밀번호와 일치하는 사용자 비밀번호를 확인하세요.

제 6 부: 훨씬 더 많은 것들 - 또는: 빠른 로그인 시도 방지하기

먼저, 이 숫자들을 봐주세요: Password Recovery Speeds - How long will your password stand up

그 링크의 표를 살펴볼 시간이 없다면, 여기 그것들의 목록이 있습니다.

약한 비밀번호를 크랙하는 것은 심지어 주판으로 해도 시간이 거의 걸리지 않습니다.

만약 대소문자를 구분하지 않는다면, 알파뉴메릭한 9자리 비밀번호를 해독하는 것은 거의 시간이 걸리지 않습니다.

심볼, 문자, 숫자, 대소문자가 복잡한 패스워드가 8자리 미만인 경우 (데스크탑 PC는 7자리 이하의 키스페이스를 몇 일이나 몇 시간 안에 전체 검색할 수 있습니다), 거의 즉시 해킹이 가능합니다.

그러나 한 번에 한 개만 시도할 수 있다면, 6자리 비밀번호를 해독하는 데에도 지나치게 많은 시간이 소요될 것입니다.

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

일반적으로 brute-force 공격에 효과적인 선택지가 세 가지 있습니다 (사전 공격에도 효과적이지만, 이미 강력한 암호 정책을 사용하고 있으므로 문제가 되지 않을 것입니다) :

N번의 실패 시 CAPTCHA를 제시합니다 (치우치우한데도 종종 효과 없음 - 하지만 여기서 반복 중입니다).

N회 실패 후 계정 잠금 및 이메일 인증 필요 (이게 일어날 $ &*!%&% ^! $& 공격이다.)

마지막으로, 로그인 쓰로틀링: 즉, 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 최상의 실천 권장 사항(반드시 읽어야 할 목록의 링크 1)에서 가져왔으며, 제한적인 측면에서 잘 알려져 있지만 최상의 실천 방법으로 간주되어야 합니다.

일반적으로 말씀드리자면, 암호 정책이 강력할수록 사용자를 기다리는 시간이 적어집니다. 대소문자 구분, 숫자 및 기호를 포함한 강력한 9자리 이상의 암호를 요구하면 사용자에게 지연 없이 2~4회 비밀번호 시도 기회를 부여할 수 있습니다. 이후에 스로틀링이 작동됩니다.

이 최종 로그인 제한 방식을 공격하는 DoS 공격은 매우 비실용적일 것입니다. 그리고 마지막으로, 항상 지속적인 (쿠키) 로그인 (및/또는 CAPTCHA 인증 로그인 양식)을 통과시키고, 합법적인 사용자가 공격이 진행되는 동안도 지연 없이 이용할 수 있도록 합니다. 이렇게 하면 매우 비실용적인 DoS 공격도 극도로 비실용적인 공격이 됩니다.

게다가 관리자 계정은 가장 매력적인 진입점이므로 보다 적극적인 쓰로틀링을 하는 것이 합리적입니다.

제 7 부: 분산 브루트 포스 공격

옆으로 얘기하자면, 더욱 발전된 공격자들은 '활동을 분산시킴'으로써 로그인 쓰로틀링을 회피하려고 할 것입니다.

IP 주소 플래깅을 방지하기 위해 봇넷의 시도를 분산하는 것입니다.

50,000가지의 가장 흔한 암호를 선택하여 단일 사용자를 대상으로 시도하는 대신(당사의 쓰로틀링으로 인해 불가능합니다), 그들은 대신 가장 흔한 암호를 선택하고 50,000명의 사용자를 대상으로 시도할 것입니다. 이렇게 하면 CAPTCHA 및 로그인 쓰로틀링과 같은 최대 시도 제한을 우회할 수 있을 뿐만 아니라, 성공 확률도 높아지며, 가장 흔한 암호는 49,995번째보다 훨씬 더 가능성이 높기 때문입니다.

각 사용자 계정의 로그인 요청 간격을 30초씩 띄우면 레이더 아래에서 숨길 수 있습니다.

여기에서는 시스템 전체에서 실패한 로그인 횟수를 기록하고, 사이트의 나쁜 로그인 빈도의 이동 평균을 기준으로 우선적으로 설정한 상한선을 모든 사용자에 적용하는 것이 가장 좋은 방법일 것입니다.

너무 추상적인가요? 다시 말해드릴게요:

귀하의 사이트는 지난 3개월간 하루 평균 120회의 잘못된 로그인이 있었다고 가정해보겠습니다. 이를 기반으로 시스템은 전역 제한을 그 3배인 24시간 동안 360회의 실패 시도로 설정할 수 있습니다. 그런 다음 모든 계정에서 실패시도의 총 수가 하루 동안이나 더 좋은 방법으로 가속화율을 모니터하고 계산 된 임계값에서 트리거될 때 시스템 전역 로그인 쓸모 없게 만드는 것을 활성화합니다 - 즉, 모든 사용자에게 짧은 지연 시간이 발생하지만 쿠키 로그인 및 / 또는 백업 CAPTCHA 로그인은 제외됩니다.

저는 분산 브루트포스 공격을 막는 데에 more details and a really good discussion of how to avoid tricky pitfals을 사용하는 것과 관련된 질문도 게시했습니다.

파트 VIII: 이중 인증 및 인증 제공자

자격증명은 익스플로잇, 비밀번호 분실, 키가 있는 노트북 도난, 또는 사용자가 낚시 사이트에 로그인을 입력하는 등 다양한 이유로 위험에 노출될 수 있습니다. 로그인을 더욱 안전하게 보호하려면, 전화 통화, SMS 메시지, 앱 또는 동글에서 받은 일회용 코드와 같은 부외적인 인자를 사용하는 이중 인증 기능을 사용할 수 있습니다. 이중 인증 서비스를 제공하는 공급업체는 여러 개가 있습니다.

인증은 자격 증명을 수집하는 다른 공급자가 처리하는 단일 로그인 서비스에 완전히 위임될 수 있습니다. 이렇게 하면 문제가 신뢰할 수 있는 제3자로 전환됩니다. Google과 Twitter는 표준 기반 SSO 서비스를 제공하고, Facebook은 유사한 소유 자산 솔루션을 제공합니다.

웹 인증에 관한 필독 링크들

번역할 수 없는 문자열입니다.

Dos and Don’ts of Client Authentication on the Web (very readable MIT research paper)

Wikipedia: HTTP cookie

Personal knowledge questions for fallback authentication: Security questions in the era of Facebook (very readable Berkeley research paper)

답변 2

폼의 기반을 둔 웹사이트 인증의 결정적인 가이드

웹사이트 보안은 매우 중요한 문제이며 많은 회사와 공공기관에서 사용자 인증 기능을 제공합니다. 그러나 많은 사용자가 도난당한 패스워드를 사용하여 보안을 약화시키기도 합니다. 폼의 기반을 둔 웹사이트 인증은 이러한 문제를 해결하기 위해 설계된 인증 시스템입니다.

폼의 기반을 둔 웹사이트 인증은 사용자 입력 필드를 사용하여 인증을 수행합니다. 이 시스템은 보통 사용자 이름과 암호를 요구하며, 이 정보는 서버에서 검증됩니다. 이 방법은 패스워드 도용을 방지할 수 있습니다.

이런 종류의 인증 방식에는 다양한 종류가 있습니다. 가장 일반적인 방법은 폼 기반 인증입니다. 이 방법은 웹사이트에 폼을 제공하여 사용자 이름과 패스워드를 입력하도록 합니다. 이 정보는 서버 측에서 검증됩니다.

또 다른 방법으로는 OAuth가 있습니다. OAuth는 사용자가 소셜 미디어 계정을 사용하여 로그인할 수 있는 방식입니다. 이 방법은 사용자가 패스워드와 같은 중요한 정보를 입력하지 않아도 됩니다.

그러나 이러한 인증 방식도 보안상의 문제가 있을 수 있습니다. 특히 폼 기반 인증에서는 XSS, SQL 삽입 등의 공격이 발생할 수 있습니다. 이러한 문제를 예방하기 위해서는 개발자들은 항상 새로운 보안 취약점에 대해 주의해야 합니다.

이러한 보안 취약점을 예방하기 위해서는 아래와 같은 방법들이 유용하게 사용됩니다.

1. 비밀번호 정책: 비밀번호 복잡도를 높임으로써 보안 수준을 높일 수 있습니다.

2. SSL: SSL은 데이터 전송 과정에서 보안 적용을 가능하게 합니다.

3. CAPTCHA: CAPTCHA는 사용자가 사람이 아닌 것을 보여주어 사용자 입력 과정에서 보안성을 확보합니다.

4. 2단계 인증: 2단계 인증은 사용자가 여러 단계를 거쳐 인증하는 방식으로, 보안 수준을 높일 수 있습니다.

이러한 방법들을 사용하여 개발자들은 더욱 안전한 폼의 기반을 둔 웹사이트 인증 시스템을 제공할 수 있습니다. 이를 통해 사용자 정보를 안전하게 보호하고 보안을 강화할 수 있습니다.