2.2 인증수행 제한

개요

로그인 등 인증 과정에서 반복적인 시도를 허용할 경우, 공격자는 자동화된 도구를 사용하여 무차별 대입 공격(Brute-force Attack)이나 사전 대입 공격(Dictionary Attack)을 시도하여 사용자 계정을 탈취할 수 있습니다. 특히 비밀번호가 취약하거나 예측하기 쉬운 경우 공격 성공률이 높아집니다.

따라서 안전한 시스템은 인증 시도 횟수에 적절한 제한을 두어야 합니다. 일정 횟수 이상 인증에 실패하면 해당 계정을 일시적 또는 영구적으로 잠그거나(Account Lockout), 추가 인증 절차(예: CAPTCHA)를 요구하여 자동화된 공격을 방어해야 합니다.

이 기준은 반복적인 인증 시도를 효과적으로 제한하여 무차별 대입 공격 등으로부터 사용자 계정을 보호하기 위한 보안 요구사항을 정의합니다.

보안 대책

  • - 인증 시도 횟수 제한: 일정 시간(예: 10분) 동안 허용되는 최대 로그인 실패 횟수(예: 5회)를 설정하고, 이를 초과하면 계정 접근을 제한합니다.
  • - 계정 잠금(Account Lockout): 설정된 횟수 이상 인증 실패 시, 해당 계정을 일정 시간 동안(예: 30분) 잠그거나, 관리자가 해제하기 전까지 영구적으로 잠급니다. 사용자에게 계정이 잠겼음을 알리고 해제 절차를 안내해야 합니다.
  • - CAPTCHA 적용: 여러 번 인증 실패 시, 사람과 기계를 구별하기 위한 CAPTCHA(Completely Automated Public Turing test to tell Computers and Humans Apart) 검증 절차를 추가하여 자동화된 공격을 방지합니다. (예: 이미지 문자 입력, reCAPTCHA)
  • - 실패 시 지연 시간 적용(Throttling): 로그인 실패 시마다 다음 시도까지의 대기 시간을 점진적으로 늘리는 방식을 적용하여 무차별 대입 공격의 효율성을 낮출 수 있습니다.
  • - 실패 기록 로깅 및 모니터링: 로그인 실패 이벤트(사용자 ID, IP 주소, 시간 등)를 기록하고, 비정상적인 대량의 실패 시도가 탐지되면 관리자에게 알림을 보내는 등 모니터링 체계를 구축합니다.
  • - 안전한 계정 잠금 해제 절차: 계정 잠금 해제 시 본인 확인 절차(예: 이메일 인증, SMS 인증)를 마련하여 공격자가 잠금을 쉽게 해제하지 못하도록 합니다.

구현 시 고려사항 (코드 예시 생략)

인증 시도 횟수 제한 및 계정 잠금 기능은 특정 언어의 코드 예시보다는 애플리케이션의 인증 로직과 데이터 저장소(DB 등) 설계에 따라 구현 방식이 달라집니다.

일반적으로 다음과 같은 로직을 구현합니다:

  • 1. 사용자 테이블 또는 별도의 테이블에 로그인 실패 횟수와 마지막 실패 시간을 기록할 컬럼을 추가합니다.
  • 2. 로그인 요청 시, 먼저 해당 계정이 잠겨 있는지 확인합니다. (예: 잠금 상태 플래그, 잠금 해제 시간 비교)
  • 3. 인증 실패 시, 해당 계정의 실패 횟수를 증가시키고 마지막 실패 시간을 업데이트합니다.
  • 4. 실패 횟수가 임계값(예: 5회)을 초과하면 계정 상태를 '잠김'으로 변경하고, 필요한 경우 잠금 해제 시간을 설정합니다.
  • 5. 인증 성공 시, 실패 횟수를 0으로 초기화합니다.
  • 6. 계정 잠금 해제 로직(시간 경과 또는 관리자 개입)을 구현합니다.

CAPTCHA는 Google reCAPTCHA 등 외부 서비스를 연동하거나, 직접 이미지 생성 및 검증 라이브러리를 사용하여 구현할 수 있습니다. 대부분의 웹 프레임워크(Spring Security, Django 등)는 인증 시도 제한 및 계정 잠금 관련 기능을 제공하거나 쉽게 구현할 수 있는 확장 기능을 지원합니다.