[정보보호론] Lecture3. Authentication(2)

※ 이 카테고리의 글들은 knu JY.Lee 교수님의 <정보보호론> 수업을 듣고 나름대로 필자가 정리한 글입니다.

※ 부족한 설명이 있거나, 잘못 알고 작성한 부분이 보인다면 편하게 댓글로 알려주시면 정말 감사하겠습니다😊

 

2-2. Security Considerations

저번 글에 이어서 패스워드 기반 인증 방식에 대해 더 알아보겠습니다.

Security Considerations (보안 고려사항)

• 패스워드의 통신 방식(How is the password communicated?):
  • 패스워드가 통신되는 방식은 매우 중요합니다. 만약 통신 중에 패스워드가 도청당할 위험이 있다면 큰 보안 문제가 발생할 수 있습니다. 암호화 기술을 사용하여 이 문제를 해결할 수 있습니다.
• 패스워드의 저장 방식(How is the password stored?):
  • 패스워드가 명확한 텍스트로 저장되는지, 암호화되었는지, 해시 처리되었는지에 따라 보안 수준이 달라집니다. 해시 처리된 패스워드는 더 안전하지만, 단순한 암호화는 해킹에 취약할 수 있습니다.
• 시스템이 패스워드를 어떻게 확인하는가(How does the system check the password?) _ 여기에 대해 자세히 알아봅시다!
  • 시스템이 패스워드를 확인하는 방식은 중요합니다. 이를 통해 공격자가 쉽게 패스워드를 추측하거나 우회하지 못하도록 해야 합니다.
• 패스워드를 추측하기 쉬운가?(How easy is it to guess the password?):
  • 기억하기 쉬운 패스워드는 종종 추측하기 쉽습니다. 따라서 보안성 높은 복잡한 패스워드를 사용하는 것이 좋습니다.

 

Common Implementation Mistakes

(1) Response Information Exposure (응답 정보 노출)

• 응답 불일치: 소프트웨어가 요청에 대해 다르게 응답할 경우, 공격자는 이를 통해 시스템 상태나 특정 정보를 유추할 수 있습니다. 즉, 공격자가 시스템 상태를 알 수 있게 되는 문제를 초래합니다. 위 이미지에서는 시스템이 해당 패스워드를 어느 사용자가 사용하고 있는지를 노출하고 있습니다.
• 대응 방법:
  • 사용자 이름 또는 패스워드가 잘못되었는지, 계정이 존재하지 않는지, 계정이 잠겨 있는지 여부와 상관없이 일반적인 오류 메시지를 반환해야 합니다.

(2) Response Discrepancy: Login (로그인 불일치)

• 잘못된 응답 예시:
  • "로그인 실패: 사용자 foo의 비밀번호가 잘못되었습니다."
  • "로그인 실패: 잘못된 사용자 ID입니다."
  • "로그인 실패: 계정이 비활성화되었습니다."
• 이러한 응답은 공격자에게 시스템의 상태나 계정 존재 여부를 노출시킬 수 있습니다.
• 올바른 응답 예시:
  • "로그인 실패: 잘못된 사용자 ID 또는 비밀번호입니다." 이와 같은 메시지는 추가적인 정보를 노출하지 않고, 사용자에게 명확한 오류를 전달합니다.

(3) Response Discrepancy: Password Recovery (패스워드 복구 불일치)

• 잘못된 응답 예시:
  • "비밀번호 재설정 링크를 보냈습니다."
  • "해당 이메일 주소는 데이터베이스에 존재하지 않습니다."
• 이러한 응답은 특정 이메일 주소가 시스템에 등록되어 있는지 여부를 공격자에게 알려줄 수 있습니다.
• 올바른 응답 예시:
  • "해당 이메일 주소가 데이터베이스에 존재한다면, 비밀번호 재설정 이메일을 보내드리겠습니다." 이와 같은 응답은 이메일 존재 여부를 숨기며, 불필요한 정보 유출을 방지합니다.

(4) Response Discrepancy: HTTP Status Codes (HTTP 상태 코드 불일치)

• HTTP 상태 코드에 따른 정보 노출: HTTP 상태 코드가 다르면 공격자는 이를 통해 추가적인 정보를 획득할 수 있습니다.
• 잘못된 응답 예시:
  • "로그인 실패: 잘못된 사용자 ID 또는 비밀번호"라는 메시지가 때로는 HTTP 200 코드로, 때로는 HTTP 403 코드로 반환될 경우 공격자는 상태 코드 차이를 악용할 수 있습니다.
• 올바른 응답 예시:
  • 항상 HTTP 403 코드를 반환하여 상태 코드 차이를 통해 정보가 노출되지 않도록 해야 합니다.

(5) Response Discrepancy: Timing (응답 시간 차이)

• 응답 시간 차이에 따른 정보 노출: 인증 코드에서 조건에 따라 응답 시간이 달라지면 공격자는 이를 악용할 수 있습니다. 공격자가 요청 처리 시간의 차이를 통해 시스템에서 사용자 이름이 존재하는지 여부나, 패스워드가 올바른지 등의 정보를 알아낼 수 있습니다.
• 좋지 않은 코드 예시:

const userExists = await lookupUserExists(username);
if (userExists) {
    const passwordHash = hash(password);
    const isValid = await lookupCredentials(username, passwordHash);
    if (!isValid) {
        throw Error('Invalid username or password');
    }
} else {
    throw Error('Invalid username or password');
}

 

• 이 코드는 사용자가 존재하는지 확인한 후에만 비밀번호를 해싱하고, 자격 증명(비밀번호)의 유효성을 검사합니다.
• 만약 사용자가 존재하지 않으면 곧바로 "Invalid username or password" 오류를 반환합니다. 이는 사용자 이름이 존재하지 않을 때와 패스워드가 틀렸을 때의 응답 시간이 다르다는 것을 의미합니다.
• 공격자는 이러한 시간 차이를 이용하여 시스템에 존재하는 사용자 이름을 추측할 수 있습니다.

 

• 좋은 코드 예시:

const passwordHash = hash(password);
const isValid = await lookupCredentials(username, passwordHash);
if (!isValid) {
    throw Error('Invalid username or password');
}

• 이 코드에서는 lookupUserExists() 함수 호출을 생략하고, 항상 패스워드를 해싱한 후 자격 증명을 확인합니다.
• 사용자가 존재하지 않더라도 같은 과정을 거치기 때문에, 응답 시간에 차이가 발생하지 않도록 설계되었습니다.
• 결과적으로, 공격자는 응답 시간을 분석해도 시스템에 존재하는 사용자 이름이나 패스워드를 추측할 수 없습니다.

 

---

Security Considerations (보안 고려사항)

• 패스워드의 통신 방식(How is the password communicated?):
  • 패스워드가 통신되는 방식은 매우 중요합니다. 만약 통신 중에 패스워드가 도청당할 위험이 있다면 큰 보안 문제가 발생할 수 있습니다. 암호화 기술을 사용하여 이 문제를 해결할 수 있습니다.
• 패스워드의 저장 방식(How is the password stored?):
  • 패스워드가 명확한 텍스트로 저장되는지, 암호화되었는지, 해시 처리되었는지에 따라 보안 수준이 달라집니다. 해시 처리된 패스워드는 더 안전하지만, 단순한 암호화는 해킹에 취약할 수 있습니다.
• 시스템이 패스워드를 어떻게 확인하는가(How does the system check the password?) 
  • 시스템이 패스워드를 확인하는 방식은 중요합니다. 이를 통해 공격자가 쉽게 패스워드를 추측하거나 우회하지 못하도록 해야 합니다.
• 패스워드를 추측하기 쉬운가?(How easy is it to guess the password?) _ 여기에 대해 자세히 알아봅시다!
  • 기억하기 쉬운 패스워드는 종종 추측하기 쉽습니다. 따라서 보안성 높은 복잡한 패스워드를 사용하는 것이 좋습니다.

 

공격자는 패스워드를 추측하기 위해 다양한 기법을 이용할 수 있습니다.

예시)

• 사전에 있는 단어를 뒤집어서 사용
• 사람 이름, 거리 이름, 도시 이름 등
• 대문자 이니셜을 이용한 패스워드
• 주(state) 내 모든 유효한 차량 번호
• 방 번호, 전화번호 등
• 문자 대체 기법 (예: '3' 대신 'E' 사용 등)

 

또한, 공격자는 해시 함수로 암호화된 패스워드를 역추적하여 실제 패스워드를 알아내는 공격 기법을 사용할 수 있습니다. (Password Hash Cracking)

해시값을 역추적하는 방법은 매우 시간이 오래 걸릴 수 있지만, GPU와 클라우드 서비스의 발달로 속도가 점점 빨라지고 있습니다.

 

• GPU 기반 하드웨어:
  • GPU는 게임을 실행하는 것뿐만 아니라, 해싱 작업을 처리하는 데에도 매우 효율적입니다.
  • 예를 들어, Nvidia RTX 4090은 초당 300기가 해시의 성능을 내어, 윈도우 NTLM 해시를 빠르게 처리할 수 있습니다.
• 클라우드 기반 크래킹 도구:
  • Crackq와 같은 클라우드 기반 도구는 패스워드를 빠르게 크래킹할 수 있습니다.
  • "비밀번호 크래킹 서비스"라는 개념도 존재하며, 서비스 형태로 제공됩니다.
  • 예시로 RTX 4090 8개를 사용한 리그는 48분 만에 대부분의 8자리 비밀번호를 크래킹할 수 있습니다.

 

Defense #1: Password Requirements (패스워드 요구 사항)

• 시스템은 사용자가 패스워드를 등록하거나 변경할 때 패스워드 규칙을 강제할 수 있습니다:
  • 사전에 있는 단어가 아닌지 확인
  • 최소 X자 이상이어야 함
  • 특수 문자가 포함되어야 함
  • 최근에 유출된 데이터베이스에 포함되지 않았는지 확인
  • 예를 들어, haveibeenpwned.com 같은 타사 서비스와 인터페이스하여 유출된 패스워드를 확인하는 것이 가능합니다.

Defense #2: Hash Stretching (해시 스트레칭)

• 해시 스트레칭 기법:
  • 여러 차례 해싱 라운드를 수행함으로써, 공격자가 비밀번호를 크래킹하는 데 필요한 자원을 크게 증가시킬 수 있습니다.
  • 다중 해싱 라운드를 사용하더라도 서버는 동시에 인증 시도가 폭주하지 않는 한 그 부하를 처리할 수 있습니다.
  • 표준화된 다중 라운드 해싱 알고리즘으로는 PBKDF2, bcrypt, scrypt 등이 있습니다.

PBKDF2 + HMAC-SHA-256 (해시 스트래칭의 예시)

 

 

---

암호 정책(Password Policies):

• 지나치게 제한적인 암호 정책(7~8자, 특정 문자의 조합, 이전 12개의 암호와 달라야 하는 규칙 등)은 사용자를 좌절시키고 보안도 약화시킬 수 있습니다.
• 사용자가 암호를 기억하는 데 어려움을 겪으며, 종종 이를 쉽게 쓸 수 있는 곳에 기록하거나 불안전하게 관리합니다.
• 이는 결과적으로 여러 시스템에서 동일한 암호를 재사용하게 만들어 보안을 약화시킬 수 있습니다.

암호 기억 용이성(Password Memorability):

• 암호의 강도와 기억 용이성은 상충하는 경우가 많습니다. 사용자는 복잡한 암호를 기억하기 어려워하며, 간단한 암호는 보안이 약합니다.
• 예를 들어, “jack123” 같은 간단한 암호는 쉽게 기억할 수 있지만 보안이 낮으며, 복잡한 암호는 기억하기 어렵습니다.
• 이에 따라 암호 생성의 전략으로는 여러 단어를 조합하여 쉽게 기억할 수 있으면서도 강력한 암호를 만드는 방법이 제시됩니다(예: "correct horse battery staple").

암호 요구 사항 - 모범 사례(Password Requirements - Best Practices):

• 구식 방법: 복잡한 암호를 요구하고, 정기적으로 암호를 변경해야 하며, 이전에 사용한 적 없는 암호만 허용하는 정책이 있습니다. 그러나 이는 사용자를 불편하게 하고, 실질적으로 보안이 강화되지 않는 경우가 많습니다.
• 업데이트된 방법: 최소 암호 길이를 설정하고, 64자를 넘지 않게 하며, 암호를 공개된 데이터와 비교하여 취약하지 않은지 확인하고, 인증 시도 수를 제한하며, 이중 인증을 권장하거나 필수로 만듭니다.

 

보안 관련 추가 취약점

가짜 로그인 페이지_ 사용자가 진짜 웹사이트로 착각하게 만들어 비밀번호를 입력하도록 유도하는 공격 방식

 

---

3. Multiple-factor Authentication

강력한 비밀번호를 설정한다고 해도 한계가 있습니다. 그럼 어떻게 보안을 더 강화할 수 있을까요?

 

• 강력한 비밀번호가 예방할 수 있는 공격:
  • Password spray: 추측 공격, 해머링, 느리고 꾸준한 시도
  • Brute force: 데이터베이스 추출 및 비밀번호 크래킹
• 강력한 비밀번호로도 막을 수 없는 공격:
  • Credential stuffing: 유출된 자격 증명을 다시 사용하는 공격
  • Phishing: 중간자 공격 또는 자격 증명 가로채기
  • Keystroke logging: 악성 소프트웨어로 키 입력 기록
  • Local discovery: 물리적 재료 탐색, 네트워크 스캐닝
  • Extortion: 협박 또는 내부자 위협
• 비밀번호를 더 강력하게 만드는 방법:
  • 다중 인증 (Multi-factor authentication)

 

다중 인증은 어떤 방식으로 할 수 있을까요?

 

(1) 사용자가 소유한 물건이나 접근 가능한 자산을 이용할 수 있습니다.

ex. sms 인증, 은행 카드나 보안 토큰을 인증

문제. 사용자가 휴대전화나 인증 수단을 분실, 도난 당하는 상황에서 추가적인 비용이 발생할 수 있습니다.

 

(2) Time-based One-Time Passwords (TOTP) 시간 기반 일회용 비밀번호를 이용할 수 있습니다.

방식은 아래와 같습니다.

• 서버가 사용자에게 비밀 키를 공유:
  • 서버는 비밀 키를 생성하고, 이를 사용자의 스마트폰 앱과 공유합니다. 이 비밀 키는 사용자가 이후 인증할 때 필요합니다.
• 앱에서 일회용 비밀번호 생성:
  • 스마트폰 앱은 카운터(시간에 기반한 값)를 초기화하고, 이 값과 비밀 키를 이용해 일회용 비밀번호를 생성합니다.
  • 코드 생성 과정은 HMAC-SHA-1 해시 함수로 처리되며, 여기에 비밀 키(K)와 카운터(C)가 입력으로 사용됩니다.
• 비밀번호 갱신:
  • 앱은 일정한 시간이 지나면 카운터 값을 변경하고, 그에 따라 새로운 일회용 비밀번호를 생성합니다. 이 비밀번호는 일정 시간 동안만 유효합니다.

>> TOTP는 비밀번호가 주기적으로 갱신되기 때문에, 고정된 비밀번호보다 훨씬 안전한 인증 방식을 제공합니다.

 

(3) 사용자만이 지니고 있는 고유한 수단인 생체 인식을 이용할 수 있습니다.

생체 인식에는 지문, 손바닥 스캔, 얼굴 인식, 홍채/망막 스캔이 포함됩니다.

생체 인식의 장점은 항상 몸에 지니고 있어 기억할 필요가 없고, 공유하거나 잃어버리기 어렵다는 점이 있습니다.

한계: 생체 인식은 비밀번호와는 달리 "확실성"이 아닌 "확률"에 기반합니다. 즉, 생체 인식 시스템은 사용자가 누구인지 완벽하게 확신할 수는 없고, 해당 사용자가 맞을 가능성에 따라 결정을 내리게 됩니다.

 

다중 인증은 더 안전하지만 사용자에게 불편함을 제공할 수 있습니다.

따라서 특정 상황에서만 다중 인증을 요구하는 것이 효과적일 수 있습니다. 예를 들어, 새로운 장치나 IP 주소를 사용할 때, 특정 국가나 위치에서 로그인할 때, 여러 계정에 로그인하려는 시도가 있을 때 MFA를 요구하는 것이 사용자 경험을 해치지 않으면서 보안을 유지하는 방법입니다.

 

마지막으로...

• 비밀번호를 안전하게 저장하기 위해 hashing과 solting은 필수적입니다: 해시는 비밀번호를 일방향 암호화하여 저장하는 방식이고, 솔팅은 각 비밀번호에 무작위 데이터를 추가하여 해시된 비밀번호가 서로 다르게 저장되도록 합니다.
• 또한, 비밀번호가 공격자에게 노출되었을 때도 사용자를 보호할 수 있는 방법이 필요합니다. 다중 인증을 사용하거나 다른 보안 계층을 추가하는 방법을 이용할 수 있습니다.
• 보안을 강화하기 위한 조치들이 때때로 사용자 경험을 나쁘게 만들 수 있습니다.

---

Summary

이번 글에서는 패스워드 기반 인증을 이용할 때 고려해야 될 보안 사항 두 가지에 대해 알아봤습니다.

첫 번째로, 시스템이 사용자 패스워드를 확인할 때 정보를 노출할 수 있는 경우에 대해 살펴보았습니다.

두 번째로, 공격자가 추측하기 어려운 패스워드를 어떻게 생성할 수 있는지 살펴보았습니다.

그리고 마지막으로 다중 인증 방식에 대해 공부했습니다.

다음 장에서는 Authorization(권한 부여)에 대해 공부해보겠습니다.