누가 액세스하고 있는지를 확인하는 인증
8.1 인증이란?
시스템에 액세스하는 권한을 가진 본인인지 아닌지를 확인하기 위해서는 [등록된 본인만이 알고 있는 정보]나 [등록한 본인만이 가지고 있는 정보] 등으로 확인.
- 패스워드
- 원타임 토큰 : 본인만이 가지고 있는 기기 등에 표시되는 한 번 쓰고 버리는 패스워드 등의 정보
- 전자 증명서 : 본인(단말기)만이 가지고 있는 정보
- 바이오 매트릭스 : 지문이나 홍채 등 본인의 신체 정보
- IC카드 등 : 본인만이 가지고 있는 정보
HTTP에서 사용하는 인증 방법
- BASIC 인증
- DIGEST 인증
- SSL 클라이언트 인증
- 폼 베이스 인증
8.2 BASIC 인증
웹 서버와 대응하고 있는 클라이언트 사이에서 이뤄지는 인증 방식.
8.2.1 BASIC 인증 수순
클라이언트는 리퀘스트를 송신.
서버는 상태 코드 401로 응답해서 인증이 필요함을 전달.
클라이언트는 유저ID와 패스워드를 Base64 형식으로 인코드한 것을 송신.
서버는 인증 성공 시, 상태 코드 200으로 응답, 실패했을 경우, 다시 상태 코드 401로 응답.
단점
Base64라는 인코딩 형식을 사용하고 있지만 이는 암호화는 아님. 따라서, 부가 정보 없이도 복호화 가능. 즉, 도청된 경우 복호화된 유저 ID와 패스워드 뺏길 수 있음.
일반 브라우저에서는 로그아웃 할 수 없음.
8.3 DIGEST 인증
챌린지 리스폰스 방식,
최초에 상대방에게 인증 요구를 보내고 상대방 측에서 받은 챌린지 코드를 사용해서 리스폰스 코드를 계산. 이 값을 상대에게 송신하여 인증.
클라이언트 ----인증 요구---> 서버
클라이언트 <---챌린지 코드---- 서버
클라이언트 : 챌린지 리스폰스 계산
클라이언트 ----리스폰스 코드---> 서버
8.3.1 DIGEST 인증 수순
클라이언트는 리퀘스트를 송신.
서버는 (상태코드 401) 인증 필요하다는 것을 전달 및 패스워드와 챌린지 코드(nonce) 송신.
클라이언트는 패스워드와 챌린지 코드에서 리스폰스 코드(response)를 계산해서 송신.
서버는 인증 성공 시, 상태 코드 200으로 응답, 실패했을 경우, 다시 상태 코드 401로 응답.
단점
BASIC 인증에 비해서는 높은 보안 등급을 제공하나, HTTPS 클라이언트 인증 등과 비교하면 낮음.
8.4 SSL 클라이언트 인증
제 3자가 위장을 하는 경우를 방지하기 위한 대책 중 하나.
HTTPS 클라이언트 인증서를 이용한 인증 방식.
8.4.1 SSL 클라이언트 인증 수순
사전에 클라이언트에 클라이언트 증명서를 배포하고 인스톨 해둘 필요가 있음.
- 인증이 필요한 리소스의 리퀘스트가 있었을 경우, 서버는 클라이언트에게 클라이언트 증명서 요구(Certificate Request 메세지 송신)
- 유저는 송신하는 클라이언트 증명서를 선택 후 보냄. (Client Certificate 메세지 송신)
- 서버는 클라이언트 증명서를 검증하여 검증 결과가 정확하다면 클라이언트의 공개키를 취득. 이후, HTTPS에 의한 암호를 개시.
8.4.2 SSL 클라이언트 인증은 2-factor 인증에서 사용된다
보통 SSL 클라이언트 인증은 대부분의 경우 단독 사용보다는 폼 베이스 인증과 합쳐서 2-factor 인증의 하나로서 이용됨.
8.4.3 SSL 클라이언트 인증은 이용하는데 비용이 필요하다
클라이언트 증명서를 이용해서 인증하기 때문에 이 증명서를 이용하기 위해 비용이 필요. 인증 기관에 의해 다르지만 증명서 한 개당 연간 수만원에서 수백만원 정도.
8.5 폼 베이스 인증
클라이언트가 서버 상의 웹 애플리케이션에 자격 정보(Credential)를 송신하여 그 자격 정보의 검증 결과에 따라 인증하는 방식.
(HTTP 프로토콜로서 사양이 정의되어 있는 아님.)
대부분의 경우, 사전에 등록해 둔 자격 정보인 유저ID와 패스워드를 입력해 웹 애플리케이션 측에 송신하고 검증 결과를 토대로 검증 성공 여부를 결정.
8.5.1 인증의 대부분은 폼 페이스 인증
BASIC 인증이나 DIGEST 인증은 사용상의 문제와 보안적인 문재로 거의 사용되고 있지 않음. 보안 등급이 높은 SSL 클라이언트 인증도 도입 비용이나 운용 비용 등의 문재로 널리 사용되지 못함.
공통 사양이 결정되어 있지 않은 폼 베이스 인증에서는 웹 사이트 별로 다르게 구현.
8.5.2 세션 관리와 쿠키에 의한 구현
표준적인 사양이 결정되어 있지 않지만 일반적으로 자주 사용되고 있는 방법으로 세션 관리를 위해서 쿠키를 사용하는 방법이 있음.
세션 관리와 쿠키를 사용하여 HTTP에 없는 상태 관리 기능을 보충.
클라이언트 ----자격정보(유저ID,패스워드)---> 서버
서버 : 유저에게 세션 ID를 발행 및 인증 상태 기록
클라이언트 <---세션 ID를 쿠키로 송신---- 서버
클라이언트 ----쿠키로 세션 ID를 송신---> 서버
서버 : 세션 ID를 검증함으로써 앞선 유저라고 판단 가능
이것은 어디까지나 하나의 예임.
일반적으로 안전한 방법으로서 패스워드를 salt라는 부가 정보를 사용해서 해시라는 알고리즘으로 계산한 값을 저장하지만, 평문의 패스워드를 서버에 그대로 보존하고 있는 것도 패스워드 누설 가능성.
