당신,, 나의 Database에 저장되어있는.. 그 사용자가 맞나요?
🔑 인증 (Authentication)
유저의 identification을 확인하는 (유저의 아이디와 비밀번호를) 절차
🤔 왜 필요한가요?
우리 서비스를 누가, 어떻게 사용하고 있는지 추적 가능하도록 하기 위해 필요합니닷!
🙋♀️ 로그인 절차
- user 아이디, 비번 생성
- user 비번 암호화해서 DB에 저장
- user 로그인 시도
유저가 입력한 비밀번호 암호화 한후 암호화되서 DB에 저정된 유저 비밀번호와 비교.
일치하면 로그인 성공! 로그인 성공하면 access token을 client에게 전송. - 유저는 로그인 성공후 다음부터는 access token을 첨부해서 request를 서버에 전송!
매번 로그인 안 해도 됨 !
🙋♀️ 유저 비밀번호 암호화
user의 비밀번호는 비밀번호 그대로 DB에 절대 안 함!!!!!!!!!!!
Password는 원본을 저장하는게 아니라 암호화해서 저장함!
통신시 개인 정보를 주고받을 때 SSL을 적용하여 암호화(HTTPS)
🤔 왜 ,, 암호화 하는 거져?
- DB가 해킹을 당하면 유저의 비밀번호도 그대로 노출 되기 때문
- 내부 개발자나 인력이 유저들의 비밀번호를 볼 수 있게 때문!
비밀번호 암호에는 단방향 해쉬 함수(one-way hash function) 가 일반적으로 쓰임!
원본 메시지를 변환하여 암호화된 메시지인 다이제스트(digest)를 생성!
🙋♀️ Bcrypt
단방향 해쉬 함수 취약점 : Rainbow table attack
단 시간 안에 데이터를 검색하기 위해 설계되었었고, 처리 속도가 최대한 빠르도록 설계 되었다.
( 이러한 속성 때문에 매우 빠른 속도로 임의의 문자열의 다이제스트와 해킹할 대상의 다이제스트를 비교할 수 있다. 눙물,, )
🤔 취약점 보완을 위해 무엇을 해야할까? ( 완벽한 암호화는 없다. 유추 시간을 늘려주자!)
- Salting
- 실제 비밀번호 이외에 추가적으로 랜덤 데이터를 더해서 해시값을 계산
- Key Stretching
-
salting 및 hashing을 여러번 반복해서 원본 값을 유추하기 어렵게 만드는 것!
단방향 해쉬값을 계산 한 후 그 해쉬값을 또 해쉬 하고 해쉬하고 반복반복! -
일반적인 장비로 1초에 50억 개 이상의 다이제스트를 비교할 수 있지만, 키 스트레칭을 적용하면? 동일한 장비
에서 1초에 5번 정도만 비교할 수 있게 함!
🔑 인가 = 당신,, 내가 생각하는 그 유저 인가?
해당 유저가 request에 해당 하는 권한이 있는지 확인하는 절차.
-
HTTP특성(stateless한 성질)으로 인해 매번 로그인을 해야함
요청을 할 때마다 유저가 맞는지 확인할 수 없으니(불편해애) 인가! 를 사용! -
headers 에 메타데이터(JSON Web Token)를 보내서 확인한다!
배송목록, 장바구니, 리뷰등 할때마다 다시 로그인할 필요 없이 Token을 같이 담아서 보낸다!
🙋♀️ JWT(JSON Web Tokens)
access token을 생성하는 여러가지 방법 중 하나!
해쉬 결과 값에 소금값과 해시값 및 반복횟수를 같이 보관하기 때문에 비밀번호 해싱을 적용하는데 있어 DB설계를 복잡하게 할 필요가 없다. 이 전체를 그대로 저장해버림!
로그인에 성공 후 access token이라고 하는 암호화된 유저 정보를 첨부해서 request를 보냄!
서버에서는 access token을 복호화 해서 해당 유저 정보를 얻게 되고 누군지 알 수 있다!
🤸♂️ header
- Token의 타입과 해시알고리즘 정보가 들어감
🤸♂️ payload
-
User-id (PK)를 넣어서 사용자가 맞는지 확인하는 것!
( 징짜 중요한 개인정보가 아니고 아이디정도만 넣는 거라,, 서비스에서만 나를 식별할 수 있는 거라 넣어도.. 됨… ㅎㅎ..) -
로그인 성공하면 user-id가 담겨있는 토큰을 넘겨줘서 다시 로그인 할 필요 없이 진행 되는 것
토큰은 만료기간을 꼭 넣어준다!!!!
🤸♂️ Signature
-
우리서버에서 발급한 토큰이 맞는지 확인하는 부분!
원본 그대로 위조되지 않고 우리가 발급한 게 맞나? -
고유한 키를 갖고 암호화를 하기 때문에 뜯어 볼 때도
그 안에 있는 유저 아이디를 갖고 아 우리 유저가 요청한 API구나를 알 수 있다! -
Front에서 JWT를 Back API 서버로 전송하면 서버에서는 전송받은 JWT의 서명부분을 복호화하여 서버에서 생성한 JWT가 맞는지 확인함!
⭐️ header와 payload의 내용은 인코딩!!!!!! 한 것!
인코딩은 형태만 변환을 해주는 것! 암호화가 아님! 개인정보를 넣으면 안돼액!!!!!!!!!!!
🙆♀️ TIL
완벽한 암호화란 없따... 머리가 디잉 해져따...
인터넷이라는 게 나의 상상 이상으로 취약한 점이 많구나 깨달았다. 이 취약성을 어떻게 하면 조금 더 보완 할 수 있을 지가 앞으로 내가 풀어야 할 숙제 ,, ! 갑자기 나 멋진 사람 된 기분이다. 꾸준히 더 더 공부하면 내가 사용자들에게 도움을 줄 수 있는 날이 오겠찌? 히히
