인증은 무엇이고 왜 하나?🎈
인증 Authentication🛒
- 인증은 회원가입과 로그인을 말합니다.
- 인증은 왜 필요할까요?
- Who? 쓰는지?
- How? 사용
- 추적 가능!
- 인증에 필요한 것은 무엇이 있는가?
- ID, EMAIL, PASSWORD
- 가장~~ 중요한건!
PASSWORD!
HOW 비번 관리해야함?🎈
법률로 강제함🛒
개인정보 보호법은 개인정보의 암호화에 대해서 다음과 같이 규정하고 있어요.
비밀번호, 바이오정보, 주민등록번호 등과 같은 주요 개인정보가 암호화되지 않고
개인정보 처리 스스템에 저장되거나 네트워크를 통해 전송될 경우, 노출 및 위*변조 등의 위험이 있으므로 암호화 등의 안전한 보호조치가 제공되어야해요.
* `암호화`는 개인정보 취급자의 실수 또는 해커의 공격 등으로 인해 개인정보가 비인가자에게 유*노출 되더라도 그 내용 확인을 어렵게 하는 보안기술이다.
즉, 시스템이 인터넷에서 격리된 네트워크에 위치하는 경우나, 예왹적인 개인정보 항목을 다루는 경우를
제외하고는 국가에서 권고하는 상용 암호화 알고리즘을 이용해 개인정보를 암호화하도록 법적으로 요구하고 있습니다.비번 어떻게 관리 하냐고요?🎈
DB 저장 시 개인 정보를 해싱하여 복원할 수 없도록 함🛒
SSL을 적용하여 암호화(HTTPS)🛒
암호화는 그래서 어떻게 하냐?🎈
단방향(Oneway) Hash🛒
-
해쉬함수는 자료구조에서 빠른 자료의 검색, 데이터의 위변조 체크를 위해서 쓰지만, 복원이 불가능한 단방향 해쉬함수는 암호학적 용도로 사용
-
(MD5, SHA-1) 이 둘은 보안에 취약함, SHA-256등이 있어요.
-
'1234'를 SHA-256 해싱하면 다음과 같아요.
-
어렵게 보이고 뭔가 식별 불가능해서 완벽해 보이지만
-
BUT 알고리즘으로 '1234'를 다시 해싱하면 항상 같은 결과가 나와요.
-
이와 같은 허점을 이용하여 가능한 경우의 수를 모두 해시값으로 만들어서 판매하는 서비스도 있어요.
-
Rainbow Table이라고 부르는 건데요. 이러한 Rainbow Table을 이용하여 해시값을 유추하는 사이트도 있어요.
-
이같은 허점을 보완하고자 SALTING과 KEY STRETCHING이라는 아이디어가 생겼어요. 비밀번호와 임의로 생성한 문자열(Salt)를 합쳐서 해싱하여 이 해시값을 저장하는 방법이에요.
SALTING & KEYSTRETCHING?🎈
소금치고 늘린다?!
bcrypt🎈
Salting & Key Stretching 대표적인 라이브러리
- bcrypt는 앞서 말한 개념들을 실제로 적용하기 편하게 해주는 대표적인 라이브러리에요
- 다양한 언어를 지원하고 있으며, 사용이 간편하여 쉽게 적용이 가능해요.
- bycrpt는 hash결과값에 소금값과 해시값 및 반복횟수를 같이 보관하기 때문에 비밀번호 해싱을 적용하는데 있어 DB설계를 복잡하게 할 필요가 없어요.
- bycrpt를 통해 해싱된 결과 값(Digest)의 구조는 아래와 같아요.
인가는 무엇일까요?🎈
인가 Authorization
-
서버는 사용자가 로그인 시,
headers에 메타데이터를 보내서 확인해요. -
META 데이터는 ->
JSON Web Token(JWT)라고 해요.
- 요청 1의 응답 1에서 200 OK와 Token 발행
- 요청 2는 발행 받은 Token과 함께 요청 보냄
JSON WEB TOKEN🎈
위 그림은 JWT의 구조에요.
헤더(header)🧨
- Token Type, Hash 알고리즘 정보
- 헤더의 내용은 BASE64 방식으로 인코딩해서 JWT의 가장 첫 부분에 기록됩니다.
- 예.
내용(Payload)🧨
- 내용에는 exp와 같이 만료시간을 나타내는 공개 클레임
- 클라이언트와 서버간 협의하에 사용하는 비공개 클레임
- 위의 두가지 요소를 조합하여 작성한뒤 BASE64 인코딩하여 두번째 요소로 위치합니다.
- 예시 -
{"user-id":1, "exp":1539517391}
서명(Signature)🧨
- JWT가 원본 그대로라는 것을 확인할 때 사용하는 부분입니다.
- 시그니쳐는 BASE64URL 인코드된 header 와 payload 그리고 JWT secret(별도 생성)을 헤더에 지정된 암호 알고리즘으로 암호화하여 전송합니다.(복호화 가능)
- 프론트엔드가 JWT를 백엔드 API 서버로 전송하면 서버에는 전송받은 JWT의 서명부분을 복호화하여 서버에서 생성한 JWT가 맞는지 확인합니다.
- 마치 계약서의 위변조를 막기위해 서로 사인하는 것과 같아요.
- 주의점! header& payload는 BASE64 인코딩한 것이므로(암호화X) 누구나 원본을 볼 수 있으니 개인정보를 담아서는 안됨!
라이브러리를 사용하여 출력한 토큰 값🧨
- 아래는 라이브러리를 사용하여 출력된 토큰 값의 모습이에요.
마무리
인증(Authentication)
단방향 해쉬<--> 양방향 해쉬
salting & key stretching
bcrypt, sha-256
인가(Authorization)
JSON Web Token
어제보다 오늘 그리고 오늘 보다 내일...