[기록일지] 📚 03주차 (로그인 로직/유지)

로그인에 대한 이해

---

로그인이란 무엇인가?

다중 사용자 시스템을 사용하기 위하여 컴퓨터에 사용자임을 알리는 일이다.

(즉, 컴퓨터가 그 사람이 맞는지를 확인하는 작업)

• 로그인의 과정에 식별과 인증의 두 단계가 존재한다.
  • 식별 / 인증

---

그렇다면 식별은 무엇이고, 인증은 무엇인가? (그리고 무엇이 다른가?)

 

식별이란?

식별 (Identification) : 수많은 데이터 중에 특정 데이터를 찾아내는(가려내는) 것

• ex) 회원 정보에서 수많은 고객 중에 특정인의 데이터를 찾아내려면, 이름과 같이 동명이인이 존재할 수 있는 데이터로는 식별 불가능. (따라서 '아이디'를 이용하는 것)
• 위의 예시와 같이 식별정보는 중복이 불가능한 유니크(Unique)한 값이여야 함
•  ex) ID는 PK로 설정되어 이미 DB에 존재하면 들어가지 않도록, 중복되지 않도록 설정
  • (PK는 절대로 중복되지 않게 되는 설정)

 

---

그렇다면 식별 정보에는 어떤것이 있을까?

식별정보는 통상적인 식별 정보와 고유 식별 정보가 존재

 

식별 정보 vs 고유 식별 정보

무슨 차이일까?

• 식별정보라는 것은 누구나가 봐도, 누구에게 공개되어도, 상관이없는 정보
• BUT ! , 고유 식별 정보는 노출이되면 위험하다고 판단됨
• 고유 식별 정보는 이 정보만 가지고도, 이 세상(혹은 국내)에서 그 사람을 식별할 수 있는 정보
• ex) 주민등록번호, 운전면허번호, 여권번호 (통상적으로 본인확인을 위한 신분증으로 사용되는 것들)

 

따라서 웹 패킷을 분석하다 보니 ID, 사번이 노출된다면?
이것은 문제가 되지 않지만
만약 웹 패킷 분석 중에 주민등록번호가 평문으로 왔다갔다 한다면?
고유식별정보이기 때문에 취약점이라고 판단!!

---

인증이란?

인증(Authentication) : 그 사람이 본인이 맞는지 확인하는 작업

• 인증정보를 이용하여 인증
• 흔히 사용하는 인증 정보 : 비밀번호 (아이디는 식별정보)

---

로그인이란?

로그인은 위의 식별과 인증을 모두 이용하는 것

• 로그인 == 식별 + 인증 -> ID와 PW를 함께 전달 한다는 것
• 식별은 수많은 사람들 중 그 사람을 집어내는 것일 뿐
• 집어내기만 해서는 의미가 없음
• 그 사람이 맞는지 확인이 필요. 그것이 인증!

---

로그인 로직

• select * from member where id='gear' (식별)
• -> 비밀번호가 맞는지 확인 (인증)
• (식별과 인증의 차이 때문에 아이디는 노출되도 상관없기 때문에 입력시에 그대로 입력되지만, 비밀번호는 별(*)로서 표기되는 것)

인증 정보는 절대로 타인에게 알려주어서는 안됨!!
(인증 정보는 보호해야 함)
결론 : 인증정보는 유출되면 위험 !!

 

---

식별과 인증을 이용하여 로그인은 어떤식으로 만들어 지는가?

 

로그인 로직 케이스

• (로그인의 로직은 여러가지가 존재하지만 식별과 인증은 필수, 그 방식이 다를 뿐)

(1) 식별 / 인증 동시 

• DB 질의를 한번에 수행하여 로그인 구현.
• (아이디와 비밀번호를 한번에 확인)

$sql = "select * from member where"
$sql .="id='$user_id' and pass='$user_pass"

"select * from member where id='____' and pass='____"

$sql.execute();
if($ret){
   // 로그인 성공
}else{
   // 로그인 실패
}

• 아이디 and 비밀번호 correct -> 답이 나옴
• 아이디 or 비밀번호 uncorrect -> 답이 안나옴
• 따라서 결과가 나오면 (if($ret)이 참이면) 성공 그렇지 않으면 실패 (결과가 나오냐 안 나오냐)

---

(2) 식별 / 인증 분리

sql = select * from member where id='____'
//(or) select pass from member where id='____'
//------> 식별
$db_pass = sql.ret['pass']

if($db_pass == $user_pass){
	// 로그인 성공
}else{
	//로그인 실패
}
//------> 인증

• 먼저 아이디를 이용한 식별과정을 거치고, 이후에 비밀번호가 맞는지 여부를 판단하는 인증 과정을 거침

---

(+) HASH

 

HASH란?

 

해시 함수(Hash function) : 임의의 길이를 갖는 임의의 데이터를 고정된 길이의 데이터로 매핑하는 단방향 함수

• 단방향 함수이기 때문에 이전의 평문을 알 수가 없음
  • (노출되어도 한 번은 안전)
• 이 비밀번호가 뭔지는 모르겠지만, hash로 바꾸고 나면 같은지 아닌지는 확인이 가능

 

그럼 암호화와는 다른것인가?

암호화(enciphering, encryption) : 어던 데이터를 이상한 문자의 글자로 내용을 모르게 모양/형태를 바꿔버리는 것

인코딩(encoding) : 어떤 데이터의 모양/형태를 바꿔버리는 것 (데이터를 효율적으로 보내기 위해서 인코딩을 사용)

해시(hash) : 어떤 데이터의 모양/형태를 바꿔버리는 것

• 모양과 형태를 바꾼다는 것에 있어서 3가지가 비슷한것 같지만, 가장 큰 차이점이 존재
• 암호화와 인코딩은 복호화와 디코딩이라는 과정을 통해 원상 복구가 가능하지만
• 해시는 한쪽 방향으로만 가능한 알고리즘으로, 기존의 모양/형태로 돌아갈 수 없음

---

 

(3),(4) (식별/인증) 동시 · 분리 (+) HASH

• 따라서 비밀번호를 저장할때 HASH화 해서 이용
• 로그인에 지장 X
• 비교하는데 문제 X
• 만약 DB가 터졌을 때(해킹 당했을 때) 해시 처리가 되어있으면 한번은 안전함
• (비밀번호가 그대로 노출되어 있다면) 크리덴셜 스터핑의 위험이 존재
• (hash를 사용함으로써 크리덴셜 스터핑으로 부터 보호)

 

로그인 로직 케이스 (1) ~ (4) 구현 

• 로그인 로직 (식별/인증/Hash)

로그인 로직에 대한 고민

• 로그인 로직(Login Logic)

---

로그인 유지 방법에 대한 이해

로그인 유지 

 

어떤 사이트에 한 번 로그인 하고 나면, 사이트 내 여러 페이지들을 접속할 때 로그인이 유지되거나, 혹은 ID/PW가 기억되어 나중에 재접속하더라도 다시 입력하지 않고 자동 로그인되는 경우가 있음

반면, 몇 분 정도 해당 사이트를 이용하지 않았다고 세션이 만료되었다는 페이지가 뜨며 로그인을 다시해야하는 경우가 발생할 수도 있음

왜 이런 일이 일어나는 걸까?

HTTP의 특성

• HTTP는 인터넷상에서 데이터를 주고 받기위한 서버-클라이언트 모델을 따르는 프로토콜로서, 클라이언트가 서버에게 요청(request)를 보내면 서버는 응답(response)를 보냄으로써, 데이터를 교환
• HTTP는 비연결성(connectionless), 무상태성(stateless)이라는 특징을 가지고 있음
• HTTP는 요청에 대한 응답을 처리 완료하게 되면, 연결을 끊어버린다는 것
• 따라서 클라이언트에 대한 이전의 상태 정보 및 현재 통신의 상태가 남아있지 않게 된다는 것

1) Connectionless Protocol 비연결지향(비연결성)
클라이언트가 서버에 요청했을 때, 그 요청에 맞는 응답을 보낸 후 연결을 끊어버리는 처리 방식

2) Stateless Protocol 무상태성(상태 정보 유지 안함)
클라이언트와 첫번째 통신에서 데이터를 주고받았다 하더라도, 두번째 통신에서 이전 데이터를 유지하지 않음

• 서버는 다수의 클라이언트와 연결을 계속 유지하게 되면 자원 낭비가 뒤따르게 됨
• 비연결성 및 무상태성의 특징을 가짐으로써 자원 낭비를 줄이는 것
• 그러나, 서버는 클라이언트를 식별할 수 없게된다는 문제가 있음
• 로그인을 하더라도, 다음 요청에서는 해당 클라이언트를 기억하지 못하므로 또 로그인을 해야한다는 것
• 한 번 로그인을 한다면 장시간 사용하지 않거나, 로그아웃을 하지 않는 이상 로그인은 유지되어야 함
  • (때때마다 로그인을 다시해야 한다면.... 상상하기 힘듬)

---

그렇다면 로그인은 어떻게 유지하는가?

HTTP의 비연결성 및 무상태성을 보완하기 위해 쿠키(Cookie) 와 세선(Session)이 사용됨

 

쿠키와 세션

 

쿠키(Cookie)

• 사용자가 어떤 웹사이트를 방문할 경우 사용자의 웹 브라우저를 통해 인터넷 사용자의 컴퓨터나 다른 기기에 설치되는 작은 기록 정보 파일
• 쿠키는 Set-Cookie HTTP 헤더를 사용하여 설정되며, 이는 웹 서버의 HTTP 응답을 통해 송신되고, 이 헤더는 웹 브라우저가 쿠키를 저장하고 차기 서버 요청시 송신할지를 지시

 

• 초창기의 웹서버는 로그인을 유지하기 위해 쿠키를 사용
  • 그런데 쿠키에는 치명적인 문제가 존재

쿠키의 출발지는 클라이언트
-> 사용자는 클라이언트
    -> 아이러니하게도 해커도 이용자이기에 클라이언트
        -> '쿠키는 클라이언트측에 자장되기 때문에'
            -> 마음껏 바꿀 수 있음

 

• 쿠키변조를 통해 다른사람으로 로그인이 가능해진다는 것
• 이러한 단점으로 인하여 클라이언트가 아닌 서버에 저장하기 위해 세션을 사용하기로 함

---

세션(Session)

• 서버에 저장되는 정보로, 세션을 식별하기 위한 식별인자 세션ID가 쿠키에 들어가서 전달됨

• 그런데? 세션 ID는 쿠키에 들어감
• 그럼 쿠키에 있으니까 바꿀 수 있는가?
• 바꿀 수야 있겠지만 세션 ID는 1,2,3,4 와 같이 단순한 숫자가 아닌 랜덤한 문자의 형태로 구성
  • ex) Cookie : PHPSESSIONID=02FE05158021DCA9080AFE40C5BAE15A
  • (유추할 수 없는 알파벳과 숫자로 구성된 일련의 문자형태로 구성)

 

그렇다면 세션 ID 는 쿠키에 들어갔는데 위험에 노출되지 않는가? NOPE 그렇지 않음.

쿠키의 세션 아이디를 다른 컴퓨터에 저장하면 ID/PW 없이 로그인이 됨

 

그렇기 때문에 해커는 세션 ID를 알아내려 함
세션 탈취 ! (세션 ID를 훔치는 것)

 

• 찾아서 바꿀 수 없는데 왜 훔치려 하는 것일까?
  • 누군가 로그인해 있다면 세션 ID는 쿠키에 들어가 있을 것이고,
  • 그것을 탈취한다면 해당 아이디로 로그인이 가능하게 되기 때문
• (그럼 너무 취약한것이 아닌가? 싶지만 이것은 HHTP에서는 가능하지만 HTTPS에서는 SSL을 사용하기 때문에 안전)

 

그런데 쿠키에 세션 값을 보관해서 로그인 할거면, 그냥 쿠키로만 로그인 유지시켜도 되지않을까?

• 쿠키로만 로그인 기능을 만드는 것은 보안 위험이 크게 존재
  • ex) 공유 PC 접근, 공유 PC에 아이디와 패스워드가 쿠키 형태로 저장되어 있으면 해당 PC에서 쿠키를 누구나 볼 수 있고 해당 정보를 통해 언제 어디서든 로그인이 가능해지기 때문
  • 따라서 세션을 이용하여 해당 정보를 본다고 해도 유추하지 못하게 하는 것

그렇다면 차라리 쿠키를 안쓰고 서버가 사용자를 기억해서 세션(Session)을 부여해주는 방법은 없을까?

• 서버가 사용자를 기억하기 위해 사용자에게 쿠키를 발급해주는 것이기 때문에 불가능
  • 그게 아니라면 마땅히 사용자마다 식별 가능한 매개체가 없기 때문

• 위에서 언급했듯 HTTP는 무상태성이라는 특징을 갖고 있음
  • 서버는 클라이언트의 상태를 보존하고 있지 않다는 것
  • BUT ! 서버에서 사용자의 식별자를 구분하기 위해 메모리에 세션 ID를 비교하기 때문에 세션 로그인 방식은 완벽한 무상태성이라고 볼 수 없음
• 그렇기 때문에 나온 기술 JWT
• 무상태성을 추구하려면 JWT 방식을 이용하는데, 클라이언트와 서버 간의 로그인 통신을 암호화(공개키-비밀키) 방식을 이용하여 서버는 사용자의 상태를 아예 저장하지 않는 방식으로 구현

 

모의 해킹 스터디 - 과제 03주차(3) - jwt

---

 

 

질문 환영, 수정 및 보완에 대한 지적 환영