ABOUT ME

-

Today
-
Yesterday
-
Total
-
  • 7일차 - HTTP 인증
    CS지식/네트워크 2021. 5. 6. 00:57

    오늘은 HTTP가 제공하는 표준적인 인증 방법과 SSL 클라이언트 인증, 폼 베이스 인증에 대해 배웠다.

    어제 배운 것에서 알 수 있듯이 HTTP는 통신 상대를 확인하지 않기에 약점이 존재한다고 하여 인증의 중요성을 강조했다.

    어제는 SSL을 통해서 인증을 구현한다고 하여 HTTP 자체에 인증 방법이 없는 줄 알았는데 오늘 배우면서 제대로 알게 되었다.

     

     

     

    1. 인증이란

    우리는 누군가와 얘기를 할 때에 서로 알고 있거나 모른다면 통성명을 하여 누군지 알고 시작한다.

    하지만 컴퓨터는 클라이언트가 누구인지, 서버가 누구인지 알 수가 없다.

    그래서 인터넷을 통한 통신에서는 상대방인지 누구인지 알 수 있도록 정보가 필요하고 정보를 통해 확인된 실체가 정말 맞는지에 대한 확신이 필요하다.

    HTTP에서는 이러한 기능을 구현하기 위해 사용하는 인증 방법이 존재한다.

    지금부터 하나씩 자세히 알아보도록 하자.

     

     

    2. BASIC 인증

    BASIC 인증은 웹 서버와 대응하고 있는 클라이언트 사이에서 이루어지는 인증 방식이다.

    BASIC 인증단계를 살펴보면 다음과 같다.

    BASIC 인증이 필요한 리소스에 리퀘스트가 들어오면 서버는 상태 코드 401 Authorization Required와 함께 인증 방식과 Request-URI의 보호 공간을 식별하기 위한 문자열을 포함해서 리스폰스를 보낸다.

    리스폰스를 받은 클라이언트는 인증을 위해 ID와 패스워드를 서버 측에 보내야하는데 ID와 패스워드 정보는 Base64라는 형식으로 인코딩되어 보내진다.

    다시 인증 정보를 받은 서버는 정보가 정확한지 판단하고 정확하다면 리소스를 포함한 리스폰스를 반환한다.

     

    BASIC 인증의 단점은 위에서 설명했듯이 인증 정보(ID, 패스워드)가 Base64라는 인코딩 형식으로 되어있지 암호화를 거치지 않았다. 즉, 추가적인 정보없이 복호화가 가능하다는 것으로 암호화된 통신경로에서는 누군가가 도청에서 정보를 뺏앗을 수 있다.

    또한, 한번 BASIC 인증을 한면 브라우저에서는 로그아웃을 할 수 없다는 문제도 존재한다.

     

     

    3. DIGEST 인증

    BASIC 인증의 약점을 보완한 인증 방법으로 챌린지 리스폰스 방식이 사용되어 패스워드를 있는 그대로 직접 보내지 않는다.

    챌린지 리스폰스 방식은 최초에 상대방에게 인증 요구를 보내고 상대방이 챌린지 코드를 보내게 된다.

    챌린지 코드를 받으면 챌린지 코드를 사용해서 리스폰스 코드를 계산한 후 이 값을 상대방에게 송신하여 인증을 하는 방법이다.

    DIGEST 인증은 BASIC 인증에 비해 보안 등급이 높지만 지난 시간에 공부한 HTTPS의 클라이언트 인증 등과 비교하면 낮다. 또한, DIGEST는 도청을 방지할 수는 있지만 위장을 방지하는 기능을 제공하지는 않는다.

     

     

    4. SSL 클라이언트 인증

    DIGEST 인증에서는 만약 누군가가 ID와 패스워드를 훔쳐 본인이 아닌 제 3자가 위장한 경우 알아챌 수가 없다.

    이를 방지하기 위해 SSL 클라이언트 인증을 사용한다.

    SSL 클라이언트 인증은 HTTPS의 클라리언트 인증서를 사용한 인증 방식으로 사전에 등록된 클라이언트의 접근인지 아닌지를 확인할 수 있다.

    SSL 클라이언트 인증을 단독으로 사용하는 거의 없고 보통은 폼 베이스 인증과 함께 2-factor인증의 하나로서 이용된다.

    2-factor 인증은 예를 들어 패스워드라는 한 개의 요소만이 아닌 이용자가 가진 다른 정보를 병용해서 인증하는 방법이다.

    요즘은 잘 사용은 안하지만 패스워드로 로그인하고 2차 패스워드를 사용하거나 OTP를 사용하는 경우가 2-factor 인증이다.

    SSL 클라이언트 인증은 클라이언트 인증서를 사용하여 진행된다고 언급했다.

    클라이언트 인증서를 이용하기 위해서는 비용이 들고 이 비용은 클라이언트의 수에 비례하므로 운용하기에는 큰 비용이 발생할 것이다.

     

     

    5. 폼 베이스 인증

    폼 베이스 인증은 클라이언트가 서버 상의 웹 애플리케이션에 자격 정보를 송신하여 그 자격 정보의 검증 결과에 따라 인증하는 방식이다.

    이 경우, 웹 애플리케이션에 따라 제공되는 인터페이스나 인증 방법이 다양하다.

    흔히 사용하는 naver나 google에서 ID와 패스워드를 입력하여 로그인하는 방식이 폼 베이스 인증 중 하나이다.

     

    HTTP가 표준으로 제공하는 BASIC 인증이나 DIGEST 인증은 보안적인 문제로 거의 사용되지 않는다.

    그리고 SSL 클라이언트 인증 같은 경우에도 비용이 많이 요구되므로 보편적으로 사용하는 방법은 아니다.

    또한, 웹 사이트의 인증 기능으로서 요구되는 기능의 레벨을 충족시킨 표준방법이 존재하지 않기 때문에

    웹 애플리케이션에서는 제각각 구현하는 폼 베이스 인증을 많이 사용한다.

    공통 사양이 없는 폼 베이스 인증은 웹 사이트 별로 구현이 가능하고 안전한 방법으로 구현하면 높은 보안 등급도 유지가 가능하다.

     

    폼 베이스 인증에서 자주 사용하는 방법은 세션 관리를 위해 쿠키를 사용하는 방법이다.

    쿠키를 사용하는 이유는 다음과 같다.

    예전에 배운 것을 기억해보면 HTTP는 상태를 기억하지 못하는 stateless 프로토콜이라고 배웠다.

    상태 관리가 안되는 HTTP에서는 한 번 접속한 이력이 있는 유저가 다음에 액세스 하더라도 다른 유저와 구별을 할 수가 없다. 이러한 점은 보완하기 위해 세션관리와 쿠키를 사용하는 것이다.

     

    폼 베이스 인증은 위에서 언급한 방법들과는 달리 표준화되어 있지 않아 정해진 룰? 같은 것이 없다.

    웹 사이트별로 그에 맞는 방법으로 적용이 가능하다는 것은 장점이지만

    패스워드 등의 자격 정보를 서버에서 어떻게 보존해야 하는지도 표준화 되어있지 않은 것은 문제가 될 수있다.

    일반적으로는 해시 알고리즘을 통해 보안이 이루어지면서 저장되지만 패스워드 그대로 저장되는 경우도 있어 보안의 위험성도 존재할 수 있다.

    댓글

Designed by Tistory.