08_누가 엑세스하고 있는지를 확인하는 인증 - 그림으로 배우는 Http Network Basic

8.1 인증이란?

서비스를 이용하는 주체가 누구인지 정확히 알아야 할 필요가 있다.

 

누가 엑세스하고 있는지를 확인하는 과정을 인증이라고 한다.

 

주체가 가지고 있는 정보나 주체만 알고 있는 정보로 확인한다.
주로 다음과 같은 것이다.

• 패스워드 : 본인만이 알고있는 문자열 정보
• 원타임 토큰 : 한번 쓰고 버리는 패스워드 등의 정보
• 전자 증명서 : 단말기가 가지고 있는 정보
• 바이오 매트릭스 : 신체정보
• IC 카드 : 카드에 칩같은 그 것

HTTP/1.1에선 다음과 같은 인증 방식이 있다.

• BASIC 인증
• DIGEST 인증
• SSL 클라이언트 인증
• 폼 베이스 인증

8.2 BASIC 인증

BASIC인증은 HTTP/1.0 이래로 지금까지 사용하고 있는 인증방식이다.

1. 상태코드 401: 인증이 필요하다!
   • Basic인증이 필요한 경우엔 상태코드 401과 함께 WWW-Authenticate헤더에 Basic을 명시해준다.
     realm에는 보내야 할 정보의 설명이나 인증 범위가 들어간다.
2. "아이디:패스워드"를 Base64 형식으로 송신
   • Basic인증에서 인증 정보를 보낼 땐, Authorization헤더에 아이디와 패스워드를 콜론(:)으로 구분한뒤, Base64인코딩된 문자열을 넣어 보낸다. 꼭 콜론일 이유는 없지만 콜론으로 구분하는 것이 표준이다.

🤔 BASIC 인증 단점

다음과 같은 단점 때문에 현재 BASIC 인증은 잘 쓰이지 않는다.

1. 인증정보가 노출된다.
   인코딩할때 쓰이는 Base64는 암호화가 아니라 매우 쉽게 인증정보를 알아낼 수 있다.
2. 로그아웃 할 수 없다.
   모든 요청이 로그인이기 때문에 애초에 로그인/로그아웃 개념이 없다고 볼 수 있다.

8.3 DIGEST 인증

DIGEST 인증은 BASIC 인증을 보완하기 위해 HTTP/1.1에서 나왔다.

1. 401와 함께 챌린지 코드(nonce)를 송신
   
   • 인증이 필요한 경우 401 상태코드와 함께 WWW-Authenticate필드에 nonce라는 챌린지 코드를 포함한다.
   • nonce는 401 상태코드의 응답이 생성될 때마다 만들어지며 리스폰스 코드를 만들때 사용된다.
   • 여기서 반드시 포함해야 하는 정보는 realm과 nonce이다.

1. 패스워드와 챌린지 코드에서 리스폰스 코드(reponse)를 계산해서 송신
     401 상태코드를 받은 클라이언트는 Authorization헤더 필드에 다음과 같은 정보를 담아야 한다.
   
   • realm, nonce: 서버에서 받은 그대로 복사한다.
   • username: 서비스에 등록된 주체의 사용자 이름이다.
   • uri: request uri로, 프론시 서버에 의해 리퀘스트 uri가 변경되는 이유 때문에 적어 둔다.
   • responce: Request-Digest라고 불리며, 패스워드와 챌린지 코드를 조합해 MD5로 암호화 한 것이다.

🧐 DIGEST 인증의 단점

BASIC을 대체하려 나왔지만 BASIC과 마찬가지로 보안 수준이 낮아 많이 사용하지 않는다.

• MD5을 사용한다.
• MD5는 해시 알고리즘으로 해시 테이블을 이용하면 비교적 빠르게 암호화가 풀릴 수 있다.
• 다음 사이트에서 해커가 된 기분을 낼 수 있다. 😎
• https://md5.gromweb.com/
  
  

8.4 SSL 클라이언트 인증

https의 클라이언트의 인증서를 사용하는 방식이다.
서버 인증서와 마찬가지로 인증 기관에서 주체를 보장해준다.

 

사전에 클라이언트가 인증서를 설치해두어야 한다.

1. 인증이 필요할 때, 서버가 Certificate Request라는 메시지를 송신해 증명서를 요구한다.
2. 사용자(사람)이 직접 클라이언트 증명서를 선택하면 클라이언트는 Client Certificate라는 메시지를 송신한다.
3. 증명서를 받은 서버는 클아이언트의 공개키를 취득한다. 그 후 HTTPS에 의한 암호를 개시한다.

위와 같이 증명서를 선택할 수 있다.

 

 

 

 

😩 자세한 예제가 없어서 잘 이해하지 못했다

SSL 클라이언트 인증은 단독으로 사용하는 경우는 적고, 폼 베이스 인증과 같이 사용한다.

SSL 클라이언트 인증의 단점

<비용문제>
클라이언트 증명서를 이용하기 위해선 비용이 필요하다.
사용자가 직접 증명서를 발급 받는 경우엔 발급 비용이 들어가고,
서비스 제공자가 직접 인증 기관을 만드는 경우엔 운영비가 들것이다.
(증명서 하나당 연 수만원에서 수백만원이 들어간다고 한다...😱)

8.5 폼 베이스 인증

봄 베이스 인증은 표준화된 사양은 아니다.
클라이언트가 서버에게 자격 정보(Credential)을 제공해 인증을 하는 방식이다.

대부분은 위와같이 폼에 사용자가 자격 정보(여기선 아이디와 비밀번호)를 입력해 서버에게 전송한다.

8.5.1 인증의 대부분은 폼 베이스 인증

HTTP가 표준으로 제공한 BASIC이나 DIGEST인증은 보안상의 이유로 사용되지 않기 때문에 대부분 폼 베이스 인증을 사용한다.

 

다른 프로토콜과 다르게 표준이 정해져 있지 않아서 구현 방식이 웹 서비스 마다 다르다.

8.5.2 세션 관리와 쿠키

여러 방법이 있지만 가장 대중적인 방법은 세션과 쿠기를 사용하는 방식이다.

2. 자격 정보가 일치하면 세션 ID 발행
   • 서버는 유저를 식별하기 위한 세션ID를 발행한다.
     이렇게 만들어진 세션ID는 인증상태와 매핑되어 저장된다.
   • 세션 ID는 Set-Cookie헤더 필드에 담아서 클라이언트에게 송신된다.
   • 세션 ID는 탈취당할 수 있으므로 기한을 정해두고 XSS (크로스사이트 스크립팅)을 예방하기 위해 쿠키에 httpOnly 속성을 부여하자.
3. 쿠키로 세션 ID를 송신
   • 클라이언트는 서버에게서 받은 세션 ID를 쿠키로 저장해 두면,
     자동으로 리퀘스트를 송신할 때마다 쿠키를 보내서 세션 ID가 서버로 전송된다.

주의할점

사용자의 자격 정보를 서버에 보존할 때, 비밀번호와 같은 민감한 정보는 평문으로 저장하지 말자!
(해시값을 저장하자)

 

또한 해시 테이블 공격을 막기 위해 salt값을 더해서 해시값을 구하는게 좋다.