인증 (Authentication)
- 인증이 필요한 이유: 우리 서비스의 사용자 및 사용자 행동양식 파악을 위해
- 비밀번호가 제일 중요함: 법규상의 강제 및 개인정보 보호를 위해
- Database에 저장 시 개인 정보를 해싱하여 복원할 수 없도록 함
암호화 방법
- 단방향 해쉬란?
- 본래 해쉬함수는 자료구조에서 빠른 자료의 검색, 데이터의 위변조 체크를 위해서 쓰이지만 복원이 불가능한 단방향 해쉬함수는 암호학적 용도로 사용합니다.
- SHA-256의 예: 1234를 해싱하면 굉장히 복잡하고 문자열+숫자의 조합이 나오는데 문제는 1234라는 비밀번호는 언제나 그 해쉬가 나오기에 역추적이 가능하다는 것.
- 따라서 모든 경우의 수에 대한 해쉬값을 생성해놓은 Rainbow Table이라는 것이 나오게 됨 --> Rainbow Attack 문제
- 이같은 허점을 보완하고자 salting과 Key Stretching이라는 아이디어가 생겨남. 비밀번호와 임의로 생성란 문자열(Salt)를 합쳐서 해싱하여 이 해시값을 저장하는 방법임.
- Salting & Key Stretching
- 입력한 비밀번호와 임의로 생성한 문자열(Salt)를 합쳐서 나오는 해시값을 저장하는 방법이 Salting
- 이것도 슈퍼 컴퓨터를 돌리면 풀리긴 풀리지만 필요한 시간을 최대한으로 늘리기 위해 Salting 및 해싱을 여러번 반복해서 원본 값을 유추하기 어렵게 만드는 것이 Key Stretching.
- bcrypt: Salting & Key Stretching 대표적 라이브러리
- bcrypt는 hash결과값에 소금값과 해시값 및 반복횟수를 같이 보관하기 때문에 DB설계를 복잡하게 할 필요성이 사라짐!
인가 Authorization
- 사용자가 서버에 로그인 하면 해당 사용자가 맞는지 확인하는 과정이 바로 인가
- Http의 특징: 1. Request/Response 2. Stateless
- 로그인을 하면 백엔드에서 JSON Web Token(JWT)를 발행하고 로그인하면 프런트에게 토큰을 body에 실어서 보낸다., 토큰은 request의 headers에 저장된다. 내가 다시
- JSON Web Token(JWT): 웹에서 인증 인가를 할 때 쓰이는 암호화 과정
- 헤더: (인코딩)
- 내용: (인코딩)만료시간을 나타내는 공개 클레임과 크랑이언트와 서버간 협의하에 사용하는 비공개 클레임을 조합하여 BASE64 인코딩하여 두번째 요소로 위치한다.
- 서명: (복호화)JWT가 원본 그대로라는 것을 확인할 때 사용하는 부분. 프론트엔드가 JWT를 백엔드 API 서버로 전송하면 서버에서는 전송받은 JWT의 서명부분을 복호화하여 서버에서 생성한 JWT가 맞는지 ghkrdls인함. 마치 계약서의 위변조를 막기 위해 사인하는 것과 같다고 생각하면 됨.