액세스 인증 방식

 

 

 

* 해당 게시글은 <그림으로 배우는 Http&Network Basic>을 읽고 정리하면서 공부하기 위해 메모하듯 작성하는 글입니다.

 

 

---

 

 

BASIC 인증

• HTTP/1.0에 구현된 기본(basic) 인증 방식으로 현재에도 일부 사용됨
• 웹 서버와 클라이언트 사이에서 이루어지는 인증

BASIC 인증 과정

1. 클라이언트가 BASIC 인증이 필요한 리소스에 리퀘스트 송신
2. 서버가 상태 코드 401로 응답→인증 필요하단 의미
   • WWW-Authenticate 헤더 필드에 인증 방식(BASIC)과 Request-URI의 보호 공간을 식별하기 위한 문자열(realm) 포함
3. 브라우저에 username, password 입력하라는 창이 뜸
4. 클라이언트가 유저 ID와 패스워드를 Base64 형식으로 인코드한 것을 포함하여 동일한 리소스에 리퀘스트 재송신
   • 유저 ID와 패스워드를 콜론(:)으로 연결한 문장을 Base64 형식으로 인코딩한 문자열을 Authorization 헤더 필드에 포함
5. 클라이언트 인증 성공시 서버 측에서 상태 코드 200으로 응답, 실패시 다시 401로 응답

단점

• BASIC 인증에 사용되는 base64 인코딩은 암호화가 아니기 때문에 아무런 부가 정보 없이도 복호화 가능
  • HTTPS처럼 암호화된 통신 경로가 아닌 경우, 복호화된 유저 ID와 패스워드를 뺏길 가능성 높음
• 한 번 BASIC 인증 진행시 일반 브라우저에서는 로그아웃 불가능→보안성 낮음

 

 

---

 

 

 

DIGEST 인증

• BASIC 인증의 약점을 보완한, HTTP/1.1에 도입된 인증 방식
• 챌린지 리스폰스 방식이 사용되어 패스워드를 있는 그대로 직접 보내는 일이 없음
  • 최초에 상대방에게 인증 요구를 보내고 상대방 측에서 받은 챌린지 코드를 이용해 리스폰스 코드 계산
  • 리스폰스 코드라는 패스워드와 챌린지 코드를 이용해 계산한 결과를 상대방에게 보내기에 BASIC 인증에 비하면 패스워드 누출 가능성 줄어듦

DIGEST 인증 과정

1. 인증 필요한 리소스에 리퀘스트 송신
2. 서버가 상태 코드 401로 응답
   • WWW-Authenticate 헤더 필드에 패스워드와 챌린지 코드(nonce 속성) 정보 기입
   • realm과 nonce 속성은 반드시 포함되어야 함
   • 챌린지 코드(nonce)는 401 리스폰스를 반환할 때마다 생성되는 유일한 문자열
     • Base64 또는 16진수 권장
     • 서버 측에서 임의로 생성
3. 브라우저에 username, password 입력하라는 창이 뜸
4. 패스워드와 챌린지 코드로부터 리스폰스 코드를 계산한 결과 포함한 리퀘스트 송신
   • 리스폰스 코드 계산 값을 Authorization 헤더 필드의 response 속성에 기입
     • username, realm, password, uri, qop 등의 정보를 MD5 알고리즘에 대입하여 계산
     • 자세한 계산 과정은 RFC2069, RFC2617 참고
   • 리퀘스트 username, realm, nonce, uri, response 해당 다섯 속성은 무조건 포함해야 함
     • realm과 nonce는 2번 과정에서 서버로부터 전달받은 값을 사용
     • username: 지정된 realm에서 인증 가능한 사용자 이름
     • uri(digest-uri): 리퀘스트 URI에 있는 URI지만, 리퀘스트 URI가 프록시에 의해 변경되는 경우도 있기에 해당 속성에 복사
     • response(Request-Digest): 패스워드 문자열을 MD5로 계산한 것→리스폰스 코드
5. 인증 성공시 서버 측에서 상태 코드 200으로 응답, 실패시 401로 응답
   • Authorization 헤더 필드를 포함한 리퀘스트를 받은 서버는 인증 정보가 정확한지 아닌지 판단
   • 정확한 경우에 리퀘스트 URI를 포함한 리스폰스 반환
     • 성공한 인증 정보를 Authentication-info 헤더 필드에 추가

단점

• BASIC 인증에 비해 높은 보안 기능을 제공하지만, HTTPS에 비하면 부족
• 패스워드의 도청 방지 위한 보호 기능을 제공하지만, 위장을 방지하는 기능은 제공하지 않음
• BASIC 인증과 마찬가지로 사용상의 문제와 대다수 웹사이트에서 요구되는 보안 등급에는 미치지 못해 잘 사용되지 않음

 

 

---

 

 

SSL 클라이언트 인증

• 제3자가 특정 사용자로 위장하는 경우를 방지하기 위해 사용되는 인증 방식
• 클라이언트 증명서를 인증할 때에 사용하는 방식→사전에 등록된 클라이언트에서의 액세스인지 확인 가능

인증 과정

• 사전에 클라이언트 증명서 필요→클라이언트에 배포하는 과정 선행되어야 함

1. 클라이언트 측에서 (인증 필요한)리소스에 리퀘스트
2. 서버 측에서 Certificate Request라는 메시지 송신: 클라이언트 증명서 요구
3. 유저 측에서 서버로 송신할 클라이언트 증명서 선택 후 다시 리퀘스트
   • Client Certificate라는 메시지 송신
4. 서버 측에서 클라이언트 증명서 검증 성공시 클라이언트의 공개키 취득→HTTPS에 의한 암호 개시

사용 현황

• SSL 클라이언트 인증과 폼 베이스 인증을 합쳐 2-factor 인증의 하나로서 이용됨
  • 패스워드와 함께 이용자가 가진 다른 정보 병용하여 인증하는 방법
  • SSL 클라이언트 인증→다른 인증정보로 패스워드 사용→본인확인 완료되는 식
• SSL 클라이언트 인증을 위해 사용자 측에서 증명서를 구입하거나, 서버 측에서 인증 기관을 만들어 안전하게 운용하는 데 비용이 필요

 

 

---

 

 

폼(FORM) 베이스 인증

• (HTTP 프로토콜로서 사양이 정의된 인증은 아님)
• 대부분의 웹 사이트에서 사용하는 사용자 인증 방식
• 클라이언트가 서버 상의 웹 애플리케이션에 자격 정보(Credential) 송신 후 서버에서 검증하여 인증하는 방식
  • 인증이 필요한 웹 사이트에 입력하는 사용자 ID, 비밀번호 등의 문자열이 자격 정보임
• 웹 애플리케이션에 따라 제공되는 인터페이스나 인증 방법이 다양함
  • 안전한 방법으로 구현시 보안성이 높아지지만, 문제 있는 구조를 하고 있는 웹사이트 또한 존재
  • 패스워드 등의 자격 정보를 서버에서 저장하는 방법 또한 표준화된 것이 없음
    • 일반적으로 안전한 방법→문자열에 salt라는 부가 정보를 추가하여 해시 알고리즘으로 계산한 값을 저장
    • 하지만 평문의 패스워드를 서버 측에서 저장하는 사례도 존재(이런 경우, 비밀번호 누설 위험성 증가)
• 대부분의 경우, 사전에 등록해 둔 자격 정보인 유저 ID와 패스워드를 입력해서 웹 애플리케이션 측에 송신하여 검증

쿠키를 통한 인증 상태 관리

• 세션 관리를 위해 쿠키를 사용하기도 함
  • 인증 성공한 유저의 상태를 유지하기 위해
  • 로그아웃 기능까지 구현 가능

세션과 쿠키를 이용한 인증 상태 관리 예시(로그인 과정)

1. 클라이언트 측에서 유저ID, 패스워드 등의 자격 정보 포함한 리퀘스트 송신
   • 보통 POST 메소드 사용해 엔티티 바디에 자격 정보 포함
   • HTML 폼 화면 표시와 입력 데이터의 송신에 HTTPS 이용
2. 서버 측에서 유저를 식별하기 위해 세션 ID 발행하고, Set-Cookie 헤더에 세션 ID 추가하여 리스폰스
   • 클라이언트에서 수신한 자격 정보를 검증
   • 유저의 인증 상태를 세션 ID와 연관지어 서버 측 저장
3. 클라이언트 측에서 세션 ID를 쿠키로 저장
4. 이후 클라이언트 측에서 다시 리퀘스트하는 경우, 저장된 쿠키가 서버 측으로 자동 전송

• 이후 로그인 정보 유지

<세션 ID 설명>

- 세션 ID는 서버에 요청을 보내는 다른 유저들을 구별하는 수단
- 세션 ID가 제3자에게 악용되면 세션 ID의 주인 행세 가능하므로 도난 및 유출에 대비
- 세션 ID는 추측하기 어려운 문자열을 사용하고, 서버 측에서는 유효 기한을 관리하는 등의 노력 필요
- 크로스 사이트 스크립팅(XSS) 등의 취약성에 대비하기 위해 쿠키에 httpOnly 속성 추가해도 좋음

---

느낀 점

책을 읽다 궁금한 점이 생겨 액세스 인증 방식에 대해 검색하다가 스프링 시큐리티 API를 이용한 폼 베이스 인증 방법에 관해 알게 되었다. 나중엔 관련 부분 공부까지 이어지지 않을까 싶다.