코드스테이츠 수강_15주차_4일차_인증, 보안 기초

코드스테이츠 수강 15주차 4일차에는 인증, 보안 기초에 대해 배웟다.

1. HTTPS 

지금까지 실습을 하거나 뭐든 웹 뮈시깽이를 할 때 우리는 HTTP 요청으로 이를 처리했다. 

그런데 HTTPS는 뭐냐 싶을 수 있는데, 생각보다 다행히, 크게 다르지 않다. 

그냥 뒤에 S 붙은 차이다. 

S가 뭐냐고? 

Secure Socket layer 라고 한다. 

시큐어.... 보안 뭐시기 아니냐? 

...어...맞어

그러면 차이 큰거 아님? 

아직 기초라서 그렇게 다르지 않으니 괜찮다. 

어려운 부분을 하는건 지금의 내가 아니다. 

미래의 나다 

아 ㅋㅋ 그냥 참고하라고 ㅋㅋ

오늘은 기초만 보고 가자. 

 

암호화

우리가 아이디, 비밀번호를 입력해서 로그인 할때, 누군가 중간에 가로채서 볼 수 있다면 싹다 털리는거다. 

실제로 우리가 실습할때, 단순히 우리가 사용하는 데이터명이나 값을 그대로 보내줘서, 마음만 먹으면 들여다 볼 수 있었을 것이다. 

HTTP 에서 로그인 할 때 

아이디 : chicken -> 서버로 전송 (chicken) -> 서버에서 해당 아이디 있다고 함 -> 로그인 허가 

비밀번호 : 9292 -> 서버로 전송 (9292) -> 서버에서 해당 비밀번호 있다고 함 -> 로그인 허가 

이 과정에서 서버에 그대로 데이터를 전송하게 되면 그 과정에서 그냥 들여다보기만 하면 언제든 내 아이디를 털어 갈 수 있다는 거다. 

 

그런데, 다행히, HTTPS에서는 암호화를 사용한다. 

HTTPS 에서 로그인 할 때 

아이디 : chicken -> chicken 을 vjovlrm으로 변경(암호화) -> 서버로 전송 (vjovlrm) -> 서버에서 해당 아이디 있다고 함 -> 로그인 허가

비밀번호 : 9292 -> 9292를 8181로 변경(암호화) ->  서버로 전송 (8181) -> 서버에서 해당 비밀번호 있다고 함 -> 로그인 허가 

중간에 내 아이디를 털어갈라고 들여다 봐도, 암호화된 아이디, 비밀번호(vjovlrm, 8181)를 보게 되므로, 암만 로그인창에 이거 넣어도 로그인이 안될거다. 
(위의 암호화는 그냥 키보드에서 옆으로 한칸씩 밀어서 썻다 ㅎ)

이렇게 암호화된 아이디, 비밀번호를 데이터베이스에 저장해놔서 vjovlrm, 8181랑 비교해서 패쓰 해주는 것이다. 

이때 암호화를 푸는 대칭키가 있어서 서버, 클라이언트가 각각 같은 키로 암호화하고, 암호를 풀기도 한다. 

"그러면 대칭키를 가로채면되네?"

대칭키를 서로 공유할때 비대칭키 방식을 사용한다. 

"비대칭키 방식이 뭐냐?"

암호 만드는 키, 암호 푸는 키 따로 있다는 거다.

뭔소리냐고?

쉽게 말하면 문 잠구는 키, 여는 키 따로 있다는 거다.

현관문에 잠구는 키, 여는키 따로 있다고 생각하자

만약 외출할 때 문 잠구는 키를 가지고 문 잠구고 나갔다가 그 키를 잃어버렷다고 하자. 

어차피 여는키 따로 있으니 괜찮다. 

"??? 열쇠 잃어버렷으니까 누가 들어오면 어쩌냐고?"

"잠구는키로 문 못여는데 뭔상관임? "

이렇게 생각하면 쉽다.
(문을 결국 여닫고 하려면 키가 두개 필요함)

 

인증서 

HTTPS에서 서버와 브라우저가 요청, 응답을 주고받을 때 인증서도 전달해서 서로 확인이 가능하다. 

쉽게 말하면 내가 네이버에 들어가서 네이버가 맞는지 확인 받으면서 네이버를 이용 할 수 있다는거다. 

이걸 왜하냐고? 

만약 누가 진짜로 작정하고 네이버랑 똑같은 사이트 만들어놓고 우리 로그인 시도하려고 아이디, 비밀번호 치면 적어놧다가 로그인 할 수 있기 때문이다. 

이렇게 되면 기를쓰고 모아놓은 네이버페이 포인트 다 털리고, 내 아이디로 비아그라 시알리스 홍보하고 다니다가 정지먹는거다.

실제 가짜 네이버 사례(왼쪽) / 오른쪽이 진짜 네이버 로그인 창이다.

이렇게 중요하면 인증서는 어떤식으로 만들어지나? 할 수 있다. 

서버에서 자체적으로 만드나? 할 수 있는데 제 3자가 만들어준다. 

보증이 가능한 제 3자(Certificate Authority, CA라고 한다.)가 인증서를 발급해주고, 로그인 할때마다 "얘 네이버 맞음 ㅎㅎ " 이라는 인증서를 보여주는 것이다. 

종종 웹서핑을 하다가 이런 화면 본적 있을 것이다. 

이거보는 순간 여기 보이스피싱 사이튼가? 한다.

위 화면이 나오는 이유가 사실 공인된 CA인증서가 없는 사이트에 접속하려 하기에, 우리의 똑똑한 브라우저가 알려주는 것이다.

 

2. Hashing

해싱은 앞에서 말한 암호화의 연장이라고 보면 된다. 

특정한 알고리즘에 의해 들어온 문자열을 암호화 하는것이 핵심이다. 

들어온 비밀번호를 위의 키보드처럼 아주 다른 것으로 바꿔버리는 것이다.

암호화 하는 알고리즘(해시)은 조건이 있다. 

1. 모든 값에 대해 해시 값을 계산 하는데 오래 걸리지 않아야 한다.
   (암호화 하는데 오랜 시간이 걸리면 -> 로그인 할때 한참걸린다.)
   
   
2. 최대한 해시값의 중복을 피해야 하며, 모든 값은 고유한 해시값을 가진다.
   (비밀번호를 암호화 했는데, 다른 비번 암호화 결과물이 똑같으면 -> 띠용? / 이를 방지해야함)
   
   
3. 아주 작은 단위 변경이라도 완전히 다른 해시 값을 가져야한다. 
   (12345 / 1236 둘다 비슷한 비밀번호지만 암호화 하면 완전 다른것으로 변해야 한다. 비슷하면 털린다. )

해시의 특징은 알고리즘으로 암호화 되어 있기 때문에, 암호화 한 해시값이 노출되어도 이걸 가지고 뭘 할 수가 없다. 

예를들어 1234라는 비밀번호가 dprkmfhwnsdd54sddf 라는 값으로 암호화 됫다고 하자. 

해커가 얻은 dprkmfhwnsdd54sddf 값이 비밀번호를 암호화 것임을 알지만 1234 라는것을 알수가..?

뭐 물론, 해쉬 알고리즘 자체를 털리면 역으로 1234를 만들수도 있다. 

그래서 또 방법이 있다. 

바로 다른 값을 첨가해서 해쉬값을 만드는 것이다. 

Salt

salt? 소금?

기본 비밀번호에 첨가해서 새롭게 만들어주는 것이라고 생각하자.

해쉬값을 만들 때 기존 비밀번호에 임의의 값을 더해서 해쉬값을 만드는 것이다.

앞에서 1234 를 해쉬로 만들면 dprkmfhwnsdd54sddf  이라고 했다. (걍 막 쓴거다 진짜 이렇진 않음)

위의 해쉬 조건에서 "아주 작은 단위 변경이라도 완전히 다른 해시 값을 가져야한다." 의 특성을 이용한 방법으로

기존 1234에 임의의 값(서버, 개발자가 지정해놓은 값)을 추가하는것이다.

결국 1234 + (임의의 값, 해커는 모름) -> 해쉬화 dprkmfhwnsdd54sddf 가 나올줄 알았는데, 다른 해쉬값이 나옴 

이렇게 되면 해커는 또 salt 값도 어디서 구해와야 한다. -> 더러워서 안털음

salt를 사용할때는 주의점이 있다. 

1. Salt는 유저와 패스워드 별로 유일한 값을 가져야 한다.
   (Salt를 돌려쓰면안됨)
   
   
2. 사용자 계정을 생성할때, 비밀번호를 변경할때마다 새로운 salt를 사용해야함
   (만약 비번 털려서 비번 바꾸는건데 salt도 똑같으면 또 털기 딱좋음)
   
   
3. Salt는 절대 재사용하지 말아야 한다. 
   
   
4. Salt는 DB의 유저 테이블에같이 저장되어야 한다.

 

3. Cookie

우리가 종종 웹사이트를 방문할때 쿠키 저장 해도 되느냐, 수집해도 되느냐 이런 문구나 팝업을 본 적이 있을것이다. 

쿠키는 한마디로 말하면, 서버가 특정 데이터를 클라이언트(브라우저 등)에 저장하는것을 말한다.

우리가 자동로그인이나 검색어 저장 등의 기능을 사용할 때 사실 쿠키에 저장해서 필요할때 뿅 하고 가져와서 쓰는 것이다.

그런데 "자동로그인을 위해 비밀번호, 아이디 등을 저장해놓앗는데 이걸 엉뚱한데 보내거나 하면 어쩜?" 할수도 있다.

그래서 쿠키 옵션 이라는게 있다.
(간략하게 설명하겠다.)

1. Domain

Domain 옵션은 같은 도메인이라면 쿠키를 전송 가능하게 하는것이다. 

뭔말이냐 할 수 있는데, 예를들어 네이버에서 자동저장된 아이디의 쿠키를 구글가서도 그대로 사용하지 않게끔 한다는 것이다.

네이버, 구글은 뭔일이야 생기냐 싶겠지만, 그냥 해커가 만들어놓은 홈페이지에서 쿠키를 조회 한다면? 털린다. 

2. Path

세부경로를 지정해서 그 부분에서 쿠키를 사용한다. 

우리가 URL을 사용해서 요청 할 때, http://www.localhost.com:3000/users/login 이런식으로 되어 잇는 URL을 사용한다. 

위의 URL의 도메인은 www.localhost.com 세부 경로는 /users/login 가 된다. 

여기서 세부경로에 해당하는 부분에서만 쿠키를 사용 가능하게 할 수 있다는 것이다. 

세부 경로에만 만족하면 되서, 그냥 /users까지만 지정 하면 /users/chciken , /users/member 등 /users 경로에 해당하는 것들 모두 쿠키를 쓸 수 있다.

3. MaxAge or Expires 

쿠키의 유효기간을 정하는 옵션이다. 

MaxAge는 쿠키가 몇초동안 유효한지 설정하는 옵션이다. 

Expires는 쿠키가 언제까지 유효한지 클라이언트 시간을 기준으로 날짜를 설정한다.

둘다 쿠키가 만료되는 기간을 정하는 옵션이다.

이 옵션이 적용되는 쿠키에 따라 다르게 불린다. 

1. 세션 쿠키 : MaxAge, Expires옵션이 없는 쿠키로, 브라우저가 닫히면 쿠키가 삭제됨 
   
   
2. 영속성 쿠키 : 브라우저가 닫혀도 쿠키는 남는다. MaxAge, Expires옵션에 따라 조건이 되어야 삭제됨

쿠키를 왜 삭제해야하느냐? 

계속 남겨놓으면 털리기 쉬워서 ㅎ

4. Secure 

해당 옵션이 적용 된 경우 HTTPS 프로토콜에만 쿠키를 전송 가능하다. 

이 옵션이 적용 안되면 HTTP, HTTPS 둘다 사용 가능 

5. HttpOnly 

자바스크립트로도 쿠키를 조회 가능하다고 한다. 

이 옵션을 설정하면 HTTP프로토콜에서만 쿠키에 접근 가능하다.
(자바스크림트로 못봄)

6. SameSite 

Same site는 요청을 보낸 Origin과 서버의 도메인, 프로토콜, 포트가 모두 같은 경우를 말한다. 

이 중 하나라도 다르면 Cross-Origin이라고 한다.

이 상태에서 3개의 옵션이 있다.

1. Lax : Cross-Origin 요청 일 시 GET 메소드에 대해서만 쿠키 전송 가능
    
2. Strict: Cross-Origin이 아닌 Same-Site 인 경우에만 쿠키 전송 가능
   
   
3. None: 항상 쿠키를 보내 줄 수 있다, 하지만 앞에서 언급한 Secure옵션이 필요(HTTPS 프로토콜에만 가능)

 

4. Session 

세션은 쿠키와 다르게, 서버가 클라이언트의 정보를 저장하는 것이다. 

예를 들어, 로그인 이후, 이 사용자는 인증 된 것인데, 특정 행동을 할때마다 계속 인증을 시도하면 자원 낭비가 발생한다.

이 회원은 인증되었다는 정보만 저장하고 그때그때 가져다 쓰면 그만이라는 것이다.

이 때 사용자가 인증에 성공한 상태를 세션이라고 한다.

세션이 만들어지면 각 세션을 구분할 수 있는 세션 아이디도 만들어지는데, 클라이언트가 뭘 할때 이 세션아이디를 같이 전달하는것으로 작동한다.
(신분증 제시하는것이라고 생각하면 편하다.)

약간 요약하면, 웹사이트에서 로그인을 유지하기위한 수단으로 쿠키를 사용하고, 쿠키에는 서버에서 발급해준 세션 아이디를 저장한다. 

이렇게 저장된 세션 아이디를 신분증마냥 사용해서 일일히 인증 안해도 되게끔 한다 이거다.

 

 

일단 오늘은 기초라서 이해한 부분이 많아서 블로그로 쓸 수 있었다...

내일부터는 어떻게 될지 ...ㅠㅠ