Chapter#8
인증
시스템에 액세스하는 권한을 가진 본인인지 아닌지를 확인하기 위해서는 '등록된 본인만이 알고 있는 정보' 혹은 '등록한 본인만이 가지고 있는 정보' 등으로 확인할 필요가 있다.
<종류>
- 패스워드
- 원타임 토큰 (일회성 패스워드)
- 전자 증명서
- 바이오 매트릭스 (지문, 홍채 등 신체 정보)
- IC 카드
HTTP에서 사용하는 인증방법
HTTP/1.1에서 이용할 수 있는 인증 방식에는 다음과 같은 것이 있다.
- BASIC 인증
- DIGEST 인증
- SSL 클라이언트 인증
- 폼 베이스 인증
BASIC 인증
HTTP/1.0에 구현된 인증 방식. 현재에도 일부 사용중. 웹 서버와 대응하고 있는 클라이언트 사이에서 이뤄지는 인증방식이다.
리퀘스트 송신 -> 상태 코드 401로 응답(인증이 필요하다 전달) -> 유저ID와 패스워드를 Base64 형식으로 인코드한 것을 송신 -> 인증 성공 시 상태코드 200응답, 실패했을 경우 다시 상태코드 401 응답
- 문제점
-> BASIC 인증에서는 Base64라는 인코딩 형식을 사용하나, 암호화는 아니기에 아무런 부가 정보 없어도 복호화가 가능
-> 한번 BASIC 인증을 하면, 일반 브라우저에서는 로그아웃할 수 없다.
DIGEST 인증
BASIC 인증의 약점을 보안하며 HTTP/1.1에 소개되어 있다. 챌린지 리스폰스 방식이 사용. 패스워드를 있는 그대로 직접 보내지 않는다.(BASIC)
리퀘스트 송신 -> 401(인증필요) 전달, 패스워드와 챌린지 코드 송신 -> 패스워드와 챌린지 코드에서 리스폰스 코드를 계산해서 송신 -> 인증 성공시 200, 실패시 401
- 챌린지 리스폰스 방식
최초에 상대방에게 인증 요구를 보내고 상대방 측에서 받은 챌린지 코드를 사용해서 리스폰스 코드를 계산한다. 이 값을 상대에게 송신하여 인증을 하는 방식 -> 리스폰스 코드라는 패스워드와 챌린지 코드를 이용해서 계산한 결과를 상대에게 보내기 때문에 BASIC에 비해 패스워드 누출 가능성이 줄어든다.
SSL 클라이언트 인증
HTTPS의 클라이언트 인증서를 이용한 인증 방식. 사전에 등록된 클라이언트에서의 액세스인지 아닌지를 확인할 수 있다.
SSL 클라이언트 인증을 할 때에는 사전에 클라이언트에 클라이언트 증명서를 배포하고 인스톨 해둘 필요가 있음.
인증이 필요한 리소스의 리퀘스트가 있었을 경우 -> 클라이언트 증명서를 요구하는 "Certificate Request"메시지 송신 -> 유저는 송신하는 클라이언트 증명서 선택 -> 클라이언트는 "Client Certificate"메시지 송신 -> 서버는 클라이언트 증명서를 검증하여 결과가 정확하다면 클라이언트의 공개키 취득 -> 이후 HTTPS에 의한 암호 개시
- SSL 클라이언트 인증은 2-factor 인증에서 사용된다.
SSL 클라이언트 인증은 대부분 단독으로 사용되지 않고, 2-factor인증의 하나로서 이용되고 있다. 즉, 첫번째 인증 정보로서 SSL 클라이언트 인증을 사용하여 클라이언트 컴퓨터를 인증 후 다른 인증 정보로 패스워드 사용하여 유저의 본인 확인.
-> 2-factor인증 : 패스워드라는 한 개의 요소만이 아닌 이용자가 가진 다른 정보를 병용해서 인증을 하는 방법 - SSL 클라이언트 인증은 이용에 비용이 필요
클라이언트 증명서를 이용할 필요가 있기에 비용이 필요하다. 인증 기관에서 클라이언트 증명서를 구입하는 비용 혹은 서버의 운영자 자신이 인증 기관을 만들어서 안전하게 운용하기 위해 들어가는 비용이다.
폼 베이스 인증
HTTP 프로토콜로서 사양이 정의되어 있는 인증 방식은 아님. 클라이언트가 서버 상의 웹 애플리케이션에 자격 정보(Credential)를 송신하여 그 자격 정보의 검증 결과에 따라 인증을 하는 방식. 대부분 사전에 등록해 둔 정보(ID, 메일주소)와 패스워드를 입력하여 검증 결과를 토대로 검증 성공 여부를 결정.
- 인증 대부분 폼 베이스 인증
BASIC, DIGEST인증은 사용상의 문제와 보안적 문제로 거의 사용되고 있지 않다. 보안 등급이 높은 SSL클라이언트 인증 또한 비용 문제로 널리 사용되고 있지 못하고 있다.
-> 세션 관리와 쿠키에 의한 구현일반적인 방법으로는 쿠키를 사용한다. 서버 측의 웹 애플리케이션 등에 의해 클라이언트가 송신해온 유저 ID와 패스워드가 사전에 등록하고 있는 것과 일치하는지 검증하며 이루어진다.
하지만 HTTP는 스테이트리스이기에 인증에 성공했던 유저라는 상태를 프로토콜 레벨에서 유지 불가.(상태 관리 불가) 세션 관리와 쿠키를 사용하여 상태 관리 기능을 보충
