기본 인증

TL;DR

인증 🔐

• 완벽한 인증이란 없다. 비밀번호는 유출될수있고, 신분증은 위조될 수 있다.
• 하지만 당신에 대한 여러 데이터는 당신이 누구인지 판단하는데 도움이 된다.

1.1 HTTP의 인증요구/응답 프레임워크

• 2. HTTP는 사용자 인증을 하는 데 사용하는 자체 인증요구/응답 프레임워크를 제공한다.
• 웹앱이 HTTP 요청 메세지를 받으면, 서버는 요청을 처리하는 대신에, 현재 사용자가 누구인지를 알 수 있게 비밀번호 같이, 개인정보를 요구하는 인증요구로 응답할 수 있다.
• 사용자가 다시 요청을 보낼때는 인증정보를 첨부해야한다.
• 인증 정보가 맞지 않으면 서버는 클라에 다시 인증요구를 보내거나 에러를 낼 수 있다.

1.2 인증 프로토콜과 헤더

• 2. HTTP는 필요에 따라 고쳐 쓸 수 있는 제어 헤더를 통해, 다른 인증 프로토콜에 맞추어 확장할 수 있는 프레임워크를 제공한다.
• 2. HTTP에는
  3. 기본인증
  4. 다이제스트 인증

  이라는 두가지 공식적인 인증 프로토콜이 있다.

• 미래에는, 사람들이 HTTP 인증요구/응답 프레임워크를 사용해 새로운 프로토콜을 고안해 낼 수 있을 것이다.

  현대에 HTTP의 인증요구/응답 프로토콜을 사용하는 인증 프로토콜로는 OAuth가 있다. OAuth는 모바일 기기같은 다양한 어플리케이션에서 API 인증을 위해 사용하는 최신 인증 프로토콜이다. (RFC6749 )

1. 요청 단계 - 인증정보 없음
2. 인증 요구 - 401과 함께 요청 반려. WWW-Authenticate 헤더에 해당 영역을 설명해 놓는다.
3. 인증 단게 - Authorization 헤더를 함께 보냄
4. 성공 단계 - 성공

WWW-Authenticate: Basic realm="Access to the staging site"

1.3 보안영역

• 2. HTTP가 어떻게 각 리소스마다 다른 접근 조건을 다루는지 알아보자.
• 웹 서버는 기밀문서를 보안 영역 realm 그룹으로 나눈다.
• 보안 영역을 저마다 다른 사용자 권한을 요구한다.

1. 기본 인증 👮‍♀️

• 기본 인증은 가장 잘 알려진 HTTP 인증 규약이다.
• 거의 모든 주요 클라와 서버에 기본 인증이 구현되어 있다.
• 기본인증에서, 웹 서버는 클라의 요청을 거부하고 유효한 사용자 이름과 비밀번호를 요구할 수 있다.
• 서버는 401 상태코드와, 클라가 접근하려고 했던 보안 영역을 WWW-Authenticate에 기술해서 응답하여, 인증요구를 시작한다.

1.1 Base-64 사용자 이름/비밀번호 인코딩 🧞‍♂️

• 2. HTTP 기본 인증은 사용자 이름과 비밀번호를 콜론:으로 이어서 합치고, base-64 인코딩 메서드를 사용해 인코딩한다.

cf__1 Base-64 인코딩

• base-64 인코딩은 8비트 바이트로 이루어져 있는 시퀀스를 6비트 덩어리의 시퀀스로 변환한다. 각 6비트 조각은 대부분 문자와 숫자로 이루어진 특별한 64개의 문자 중에서 선택된다.
• base-64 인코딩은 바이너리, 텍스트, 국제 문자 데이터를 문자열로 받아서 전송할 수 있게, 그 문자열을 전송 가능한 문자인 알파벳으로 변환하기 위해 발명됐다.
• base-64 인코딩은 국제 문자나 HTTP 헤더에서 사용할 수 없는 문자(큰따옴표, 콜론, 캐리지 리턴)을 포함한 사용자 이름이나 비밀번호를 보내야할 때 유용할 수 있다.

1.2 프락시 인증 🐝

• 중개 프락시 서버를 통해 인증할 수도 있다.

• 프락시 서버에서 접근 정책을 중앙 관리할 수 있는 장점이 있음

• 상태코드: 407

• Proxy-Authenticate (like WWW-Authenticate)

• Proxy-Authorization (like Authorization)

1.3 기본 인증의 보안 결함 🤦‍♀️

• 기본 인증은 악의적이지 않은 누군가가 의도치 않게 리소스에 접근하는 것을 막는데 사용하거나, SSL 같은 암호 기술과 혼용한다.

1. 누구나 디코딩할 수 있다.

• 기본인증은 쉽게 디코딩할 수 있는 형식으로 네트워크에 전송한다.
• 메모하기 어렵지 않은 일반 문자열로 보내진다.
• base-64로 인코딩된 비밀번호는 사실상 비밀번호 그대로 보내는 것과 다름없다.
• 2. HTTP 트랜잭션을 SSL 암호화 채널을 통해 보내거나 보안이 더 강화된 다이제스트 인증 같은 프로토콜을 사용하는 것이 좃다.

2. 재전송 공격을 예방하지 않는다.

• 복잡한 방식으로 인코딩 되어있더라도, 해당 인코딩 문자열을 캡쳐한 다음, 그대로 원 서버에 보내서 인증을 성공하고 서버에 접근할 수 있다.
• 기본인증은 재전송 공격을 예방하기 위한 어떤 일도 하지 않는다.

3. 한번 뚫리면..

• 사용자는 대부분의 사이트에 같은 아이디와 비밀번호를 사용한다.
• 한번 도용되면 중요한 사이트에서도 접근할 수 있다.

4. 기본인증의 정상동작 보증 못함

메세지의 인증헤더를 건드리지는 않지만, 그 외 다른 부분을 수정해서 트랜잭션의 본래 의도를 바꿔버리는 프락시나 중개자가 중간에 개입하는 경우, 기본 인증은 정상적인 동작을 보장하지 않는다.

5. 가짜 서버

• 기본인증은 가짜 서버의 위장에 취약하다.
• 가짜 서버에 연결되어 있지만, 사용자는 검증된 서버에 연결되어있다고 믿고, 개인정보를 노출할 수 있다.

기본인증은 다른 사람들이 보지 않기를 원하긴 하지만, 보더라도 치명적이지 않은 경우에는 여전히 유용하다. 기본 인증보다 더 복잡하고 강력한 보안 관련 속성인 다이제스트 인증을 다음 포스팅에서 알아보자.

• HTTP 완벽가이드  책을 보고 이해한 내용을 정리 한 글입니다.

참고자료

• Oauth와 춤을 
• Oauth1 관련 글 
• RFC6749 
• HTTP 인증 

Related