인증
인증이란 누가 엑세스 하고 있는지 알 수 없다
상대방에게 이름을 알려달라고 해야 한다
다만 상대방에게 확인을 하더라도 실재로 누구인지는 알 수 없다
실제로 알기 위해서는 본인 인증을 해야 한다
주로 사용되는 인증 방법
- 패스워드
- 원타임 토큰: 한 번만 쓰고 버리는 패스워드 등의 정보
- 전자 증명서: 본인만이 가지고 있는 정보
- 바이오 매트릭스: 지문이나 홍채 등의 정보
- IC 카드 등의 정보
단 위의 정보를 제시할 수 있다면 본인이 아니더라도 인증을 통과하게 된다
HTTP 에서 사용하는 인증 방법
- BASIC 인증
- DIGEST 인증
- SSL 클라이언트 인증
- 폼 베이스 인증
BASIC 인증
BASIC 인증은 HTTP/1.0 에 구현된 인증 방식으로 현재 일부 사용되고 있다
BASIC 인증은 웹 서버에 대응하고 있는 클라이언트 사이에서 이뤄지는 인증 방식
BASIC 인증에서는 Base64 라는 인코딩 형식을 사용하고 있지만 암호화가 아니기 때문에
아무런 부가 정보 없이 복호화 할 수 있다
HTTPS 등에서 암호화되지 않은 통신 경로 상 BASIC 인증이 도청된 경우
복호화된 유저 ID 와 패스워드를 뺴앗길 가능성이 있다
한 번 BASIC 인증을 하면 일반 브라우저에서는 로그아웃할 수 없다
BASIC 인증은 사용상 문제와 보안 등급에 미치지 못한다는 면에서 그다지 사용되고 있지는 않다
DIGEST 인증
HTTP/1.1 에 소개되어 있다
BASIC 인증의 약점을 보안한다
DIGEST 인증에는 챌린지 응답 방식이 사용되고 있어
BASIC 인증과 같이 패스워드를 있는 그대로 보내는 일은 없다
챌린지 응답 방식은 최초 상대방에게 인증 요구를 보내고 상대방 측에서 받은 챌린지 코드를 사용해
응답 코드를 계산한다 이 값을 상대에게 송신하여 인증을 하는 방식이다
응답 코드라는 패스워드와 챌린지 코드를 이용해서 계산한 결과를 상대에게 보내기 때문에
BASIC 인증과 같은 방식에 비하면 패스워드가 누출될 가능성이 줄어든다
DIGEST 인증도 BASIC 인증과 마찬가지로 사용상 문제와 보안 등급이 미치지 못한다는 점에서
잘 사용되지 않는다
SSL 클라이언트 인증
SSL 클라이언트 인증은 HTTPS 의 클라이언트 인증서를 이용한 인증 방식으로
사전에 등록된 클라이언트에서의 엑세스인지 아닌지를 확인할 수 있다
SSL 인증 순서
SSL 클라이언트 인증 시 사전에 클라이언트 증명서를 배포하고 설치해야 한다
- 인증이 필요한 리소스의 요청이 있을 경우 서버는 클라이언트에게 Certificate Reqeust 메시지를 송신하여 클라이언트 증명서를 요구한다
- 유저는 송신하는 클라이언트 증명서를 선택한다 클라이언트는 Client Certificate 라는 메시지를 송신한다
- 서버는 클라이언트 증명서를 검증하여 검증 결과가 정확하다면 클라이언트 공개 키를 취득한다
이후 HTTPS 에 의한 암호를 개시한다
SSL 클라이언트 인증은 2-factor 인증에서 사용된다
SSL 클라이언트 인증은 대부분의 경우 단독으로 사용되지 않고
이후 다룰 폼 베이스 인증과 합쳐 2-factor 인증의 하나로 이용되고 있다
2-factor 인증은 두 가지 인증 방식을 병용하여 인증 하는 방법이다
SSL 클라이언트 인증을 사용하여 클라이언트 컴퓨터를 인증하고 패스워드 등을 사용하여 유저 본인 확인을 한다
SSL 클라이언트 인증은 비용이 필요하다
SSL 클라이언트 인증에는 클라이언트 증명서를 이용할 필요가 있다
클라이언트 증명서에는 비용이 필요하다
이 경우에 비용은 인증 기관에서 클라이언트 증명서를 구입하는 비용이나
안전하게 운용하기 위해 들어가는 비용이다
폼 베이스 인증
폼 베이스 인증은 HTTP 프로토콜로 사양이 정의되어 있는 인증 방식은 아니다
클라이언트가 서버 상 웹 애플리케이션에 자격 정보를 송신하여
그 자격 정보의 검증 결과에 따라 인증 하는 방식이다
웹 애플리케이션에 따라 제공되는 인터페이스나 인증 방법이 다양하다
대부분의 경우에는 사전 등록해 둔 자격 정보인 유저 ID 와 패스워드를 입력하여 검증을 한다
인증의 대부분은 폼베이스
HTTP 표준인 BASIC 이나 DIGEST 인증은 사용 문제와 보안적 문제로 거의 사용되지 않는다
SSL 클라이언트 인증은 비용 문제로 널리 사용되기는 어렵다
웹 사이트 인증 기능으로 요구되는 표준이 없기 때문에
웹 애플리케이션에서 제각각 구현하는 폼 베이스 인증을 채용할 수 밖에 없다
공통 사양이 결정되어 있지 않기 때문에 서비스 별로 다르게 구현되어 있다
그렇기 때문에 안전하지 않은 웹 사이트도 종종 발견할 수 있다
세션관리와 쿠키에 의한 인증 구현
폼 베이스 인증은 표준적인 사양이 결정되어 있지 않지만 일반적으로 자주 사용되고 있는 방법은
세션 관리를 위해 쿠키를 사용하는 방법이 있다
폼 베이스 인증의 인증 자체는 서버 측 웹 애플리케이션 등에 의해 클라이언트가
송신해온 유저 ID 와 패스워드가 사전에 등록하고 있는 것과 일치하느지를 검증하면서 이루어진다
HTTP 는 스테이스리스 프로토콜이기 때문에 방금 전에 인증을 성공했던 유저라는 상태를 유지할 수 없다
때문에 세션 관리와 쿠키를 사용하여 상태 관리 기능을 보충한다
- 클라이언트와 서버 유저 ID 나 패스와드 등의 자격 정보를 포함한 요청 송신
보통은 POST 메소드를 사용하여 엔티티 바디에 자격 정보 저장
주로 HTML FORM 으로 화면을 표시하고 HTTPS 통신을 이용한다 - 서버 측은 유저 식별을 위해 세션 ID 를 발행한다 클라이언트에서 수신한 자격 정보를 검증하는 것으로 인증을 한다
해당 유저의 인증 상태를 세션 ID 와 짝으로 서버에 기록한다
클라이언트에 송신할 때는 Set-Cookie 헤더 필드에 세션 ID 를 저장하여 응답을 반환한다 세션 ID 를 탈취당하면 인증을 악용할 수 있기 때문에 주의해야 한다
세션 ID 는 추측하기 어려운 문자열을 사용, 유효 기한을 설정하는 등으로 보안을 유지할 필요가 있다
크로스 사이트 스크립틍 등의 취약성이 발생했을 때에도 피해를 줄이기 위해
httponly 속성을 부여한다 - 서버 측에서 세션 ID 를 받은 클라이언트는 쿠키로 저장해둔다
다음 요청 때 브라우저가 자동으로 쿠키를 송출하기 때문에 세션 ID 가 서버에 송신된다
폼 베이스 인증에서는 자격 정보를 교환하는 방법은 표준화되어 있지 않다
일반적으로 패스워드에 salt 라는 부가 정보를 사용하여 해시 값을 저장한다
