Hash란?
본래 해쉬(hash)함수는 자료구조에서 빠른 자료의 검색, 데이터의 위변조 체크를 위해서 쓰이지만, 복원이 불가능한 단방향 해쉬함수는 암호학적 용도로 사용합니다.
- (MD5, SHA-1)(둘은 보안취약),
SHA-256등이 있습니다. 1234를SHA-256해싱하면 다음과 같습니다.
03ac674216f3e15c761ee1a5e255f067953623c8b388b4459e13f978d7c846f4- 결과만 봐서는 당장 식별이 불가능하므로 완벽해보입니다.
하지만 같은 알고리즘으로1234다시 해싱하면 항상 같은 결과가 도출됩니다. - 이와 같은 허점을 이용해서 가능한 경우의 수를 모두 해시값으로 만들어서 판매하는 서비스도 존재합니다.
- http://project-rainbowcrack.com/table.htm
Rainbow Table이라고 부르는 것인데요. 이러한 Rainbow Table을 이용해서 해시값을 유추해주는 사이트도 존재합니다.
- http://project-rainbowcrack.com/table.htm
- 이같은 허점을 보완하고자
salting과Key Stretching이라는 아이디어가 생겨났습니다. 비밀번호와 임의로 생성한 문자열(Salt)를 합 쳐서 해싱하여 이 해시값을 저장하는 방법입니다.
SALTING & KeyStretching
- 단순해쉬값이 해킹에 쉽게 노출되기 때문에
Salting이라는 아이디어가 생겨났습니다. 입력한 비밀번호와 임의로 생성한 문자열(Salt)를 합쳐서 해싱해서 이 해시값을 저장하는 방법입니다.
물론 이때에 비교를 위해 해시값과 소금(Salt)값을 같이 저장해야 합니다. - 여기에 해커가 패스워드 무작위 대입을 통해 해시값을 계산하는데 필요한 시간을 대폭 늘리기 위해 Salting및 해싱을 여러번 반복해서 원본 값을 유추하기 어렵게 만드는 것이
키 스트랫칭(Key Stretching)입니다.
bcrypt
Salting & Key Stretching 대표적 라이브러리
- bcrypt는 앞서 말한 개념들을 실제로 적용하기 편하게 해주는 대표적인 라이브러리입니다. 다양한 언어를 지원하고 있으며, 사용이 간편하여 쉽게 적용이 가능합니다.
- bcrypt는 hash결과값에 소금값과 해시값 및 반복횟수를 같이 보관하기 때문에 비밀번호 해싱을 적용하는데 있어 DB설계를 복잡하게 할 필요가 없습니다.
bcrypt를 통해 해싱된 결과 값(Digest)의 구조는 아래와 같습니다.
JWT
Http의 특징으로 request / response의 stateless한 성질 때문에 서버는 유저가 로그인 했을경우 로그인한 상태를 유지할 수 없습니다. 그래서 서버는 headers에 메타데이터를 받아 로그인 했다는 것을 알게되고, 이 메타테정보를 JSON Web Token 일명 JWT라고 합니다.
- JWT 구조
Header
- 토큰의 타입과 해시알고리즘 정보가 들어갑니다.
- 헤더의 내용은 BASE64 방식으로 인코딩해서 JWT의 가장 첫 부분에 기록됩니다.
- ex) {“alg”: “HS256”, “typ”: “JWT”}
Payload
- 내용에는 exp와 같이 만료시간을 나타내는 공개 클레임
- 그리고 클라이언트와 서버간 협의하에 사용하는 비공개 클레임
- 위의 두가지 요소를 조합하여 작성한뒤 BASE64 인코딩하여 두번째 요소로 위치합니다.
- ex) { “user-id” : 1, “exp”: 1539517391 }
Signature
- JWT가 원본 그대로라는 것을 확인할 때 사용하는 부분입니다.
- 시그니쳐는 BASE64URL 인코드된 header 와 payload 그리고 JWT secret(별도 생성)을 헤더에 지정된 암호 알고리즘으로 암호화하여 전송합니다.(복호화 가능)
- 프론트엔드가 JWT를 백엔드 API 서버로 전송하면 서버에서는 전송받은 JWT의 서명부분을 복호화하여
서버에서 생성한 JWT가 맞는지 확인합니다.
마치 계약서의 위변조를 막기위해 서로 사인하는 것과 같다고 보시면 됩니다.
주의할 점은 header와 payload는 BASE64 인코딩한 것이므로(암호화아님) 누구나 원본을 볼 수 있으니 개인정보를 담아서는 안됩니다.
게으른 개발자