로그인 로직 [3주차]

 

로그인이 어떻게 이루어지는지, 로그인을 어떻게 유지하는지.

이번 시간에는 로그인에 대해 공부했다.

---

 

로그인이란?

 

로그인의 정의를 찾아보면 이렇게 나온다.

접근 허가 증명을 얻기 위해 사용자 인증으로 개인이 컴퓨터 시스템에 접근하는 작업

 

로그인을 쉽게 설명해보자면 내가 나인 것을 증명하는 행위(?)라고 할 수 있다. 

하루에도 몇번씩 나를 증명하는 행위를 하고 있을 것이다. 지금 이 글을 쓰기 위해 티스토리에 로그인한 것을 포함해서.

 

게임을 비유로 들어보자. 만약 어떤 게임을 하고 싶다면 내 계정을 만들어야 한다. (계정이 필요없는 플래시 게임도 있긴 하지만) 그래야 게임에서 내가 한 것들을 이어갈 수 있으니까. 그러면 게임사이트에서 로그인을 해야 하고 그 과정에서 ID와 비밀번호가 필요하다. 게임사의 서버는 입력한 ID가 회사 DB에 있는지 확인할 것이고, ID를 확인한 후 비밀번호까지 대조해서 맞다면 그 계정으로 로그인을 허락해준다. 이것이 로그인의 과정이다.

 

 

 

 

식별 / 인증

사실 위에서 식별과 인증에 대해 다 설명했다. ID가 DB에 존재하는지 확인하는 작업이 식별이고, 해당 ID 계정의 비밀번호가 맞는지 확인하는 작업이 인증이다. 이렇게 간단하게 넘어가긴 그러니 고급진 단어로 한번 더 정리하겠다.

식별(Identification) : 사용자의 정보를 입력하여 시스템이 그 사용자를 식별할 수 있도록 하는 것.

인증(Authentication) : 시스템에서 사용자가 제공한 정보(아이디와 비밀번호, 생체인식정보 등)가 실제로 그 사용자의 것인지 확인하는 것.

 

인증과정에서 ID와 비밀번호가 아닌 생체인식정보도 사용되는 것을 볼 수 있다. 결국 어떤 방식을 사용하든 사용자의 자격을 증명하는 것이 로그인이고 그 과정에서 핵심적인 것이 식별과 인증이다.

 

 

해시(Hash)

해시는 문자열을 고정된 길이의 암호화된 문자열로 변환하는 단방향 암호화 알고리즘 함수다. 단방향이란 말은 암호화는 가능하지만 복호화는 불가능하다는 뜻인데 아래의 그림을 보면 이해할 수 있다.

1. Hash

 

그 이유는 해시의 결과값이 유일하지 않기 때문이다. 문자열 "John Smith"와 "Sandra Dee" 해시 알고리즘을 통해 둘 다 "02"라는 값으로 변환된다. 이렇게 되면 암호화된 "02"를 복호화하기 위해 어떤 문자열로 돌아가야 하는지 알 수 없다. 그래서 해시는 동일한 평문을 해시 함수로 암호화해서 그 값이 맞는지 대조하는 식으로 활용한다.

 

로그인 과정에서는 비밀번호를 저장하는데 해시 함수가 사용된다. 비밀번호를 평문으로 보관하는 것은 보안상 위험한 행동이기 때문이다. 해시를 통해 암호화된 비밀번호를 저장한다면 DB가 털려도 해시의 특성 때문에 원래 비밀번호를 찾기 어려울 것이다. 물론 레인보우 테이블을 통해 원래 평문을 찾는 방법이 있다지만 평문에 문자열을 덧붙여서 암호화하는 솔트(Salt) 기법 등 추가적인 방법을 더한다면 적당한 보안을 유지할 수 있다.

 

 

 

 

로그인 유지 방법

실습을 하면서 실제로 로그인 페이지를 만들어보니 로그인이 한번만 한다고 해서 끝나는 게 아니다. 페이지를 이동할 때마다 로그인 상태를 유지하는 것이 있어야 한다는 것을 깨달았다. 물론 그럴 때마다 DB에 접근해서 ID와 비밀번호를 확인하는 건 서버에 엄청난 부담이고, 최소한의 비용으로 로그인을 유지할 다른 방법이 필요하다.

 

 

1. 쿠키(Cookie)

가장 먼저 사용된 방법이 쿠키를 사용하는 것이다. 쿠키는 브라우저(클라이언트 측)에 저장되는 정보다. 사용자가 ID와 비밀번호로 로그인 성공 시 서버에서 로그인을 인증하는 쿠키를 사용자에게 전달한다. 그럼 사용자는 다음 요청부터 받은 쿠키를 함께 전달하여 자신을 증명하면 된다. 아래의 그림을 보면 쉽게 이해할 수 있다.

2. 쿠키

 

쿠키는 브라우저가 종료되어도 만료시간이 될 때까지는 사라지지 않는다는 이점이 있다. 그러나 브라우저마다 지원하는 쿠키의 형식이 달라 브라우저마다 쿠키를 생성해야 한다.

 

쿠키는 다음과 같은 정보를 포함하고 있다.

1. 쿠키를 구별하는 이름
2. 쿠키에 저장되는 값
3. 쿠키 유지 시간
4. 쿠키를 전송할 도메인
5. 쿠키를 전송할 요청 경로

 

그림에서 볼 수 있듯이 쿠키에는 중요한 정보가 포함되어 있다. 그래서 쿠키를 포함한 HTTP 요청 시 패킷이 탈취된다면 정보가 그대로 노출된다는 점과 쿠키의 내용을 위/변조할 수 있다는 문제점이 있다. 그리고 매번 패킷에 실어 보내기에 쿠키에 저장할 정보량에도 한계가 있다.

 

 

2. 세션(Session)

그래서 세션을 사용한다. 세션은 쿠키 속에 필요한 정보 대신 세션 ID를 주고받는 방법이다. 사용자가 ID와 비밀번호로 로그인을 하면 서버에 존재하는 세션 저장소에 해당 정보를 가진 세션을 생성하여 그것을 식별할 수 있는 세션 ID를 사용자에게 전달한다. 그러면 사용자는 다음 요청부터 받은 세션 ID를 쿠키에 포함시켜 서버에 전달하면 되는 것이다.

여전히 쿠키를 사용하는 방식이지만 쿠키 속에 포함된 내용이 탈취되어도 상관없는 세션 ID값이라는 점에서 보안성이 좋은 방법이다. 

3. 세션

 

단점도 역시 존재한다. 세션이 서버에 저장되기에 세션 저장소를 따로 두는 것과 같이 서버의 자원이 소모된다는 점과 이에 따라 사용량이 많을 경우 서버에 부하가 심할 수 있다는 점이다. 그리고 세션 ID가 탈취되면 정보의 노출을 막을 수는 있겠지만 해당 ID의 사용자로 위장할 수 있는 문제도 존재한다.

 

 

+ JWT(Json Web Token)

쿠키와 세션 외에도 토큰으로 인증을 하는 방식이 있다. 대표적인 것이 jwt인데 먼저 그림을 보자.

4. JWT

 

기본적인 구조는 쿠키와 비슷하다. 이 말은 세션을 사용하는 방식과 같이 서버에 저장소를 둘 필요 없어 서버 측에 부담이 없다는 말이다. 그리고 서버에 요청시 포함되는 jwt에 데이터가 포함되어 있어 DB에 접근할 필요도 없고, 서버측에서 jwt를 검사하기 때문에 쿠키처럼 위/변조할 수도 없다.

 

그러나 역시 문제점은 존재하는 법. JWT의 구조를 살펴보면 header, payload, signature로 나누어져 있는데, 정보를 저장하는 header와 payload 부분은 암호화가 아닌 Base64로 인코딩이 되어 있어 정보의 노출 위험이 있다. 그래서 중요한 정보를 포함할 수는 없다. 게다가 jwt 자체가 크기가 큰 편이라 네트워크에 부하가 가해질 수 있고, 또 토큰을 발행하면 이것에 대한 악의적인 행동에 대해 대처할 수 없다는 점이다. 

 

확실히 단점이 없는 완벽한 방법은 없는 것 같다. 여러 사이트나 기관들도 이 중에서 각자에게 맞는 방식을 사용하고 있으니 이 3가지 방식의 장단점을 잘 숙지하여 필요한 상황에 적절하게 사용할 줄 아는 지혜가 필요해 보인다.  

 

 

---

참조

• 해시 함수

해시 함수 - 위키백과, 우리 모두의 백과사전

 

• [Web] 쿠키(Cookie)와 세션(Session)의 차이, 쿠키란? 세션이란?

[Web] 쿠키(Cookie)와 세션(Session)의 차이, 쿠키란? 세션이란?

 

• 1. JWT 토큰 인증과 (쿠키, 세션, 토큰)

1. JWT 토큰 인증과 (쿠키, 세션, 토큰)