1. 인증(Authentication)

로그인 절차

1. 유저 아이디와 비번 생성
2. 유저 비번 암호화 해서 DB에 저장.
3. 유저 로그인 -> 아이디와 비밀번호 입력
4. 유저가 입력한 비밀번호 암호화 한후 암호화되서 DB에 저정된 유저 비밀번호와 비교.
5. 일치하면 로그인 성공
6. 로그인 성공하면 access token을 클라이언트에게 전송.
7. 유저는 로그인 성공후 다음부터는 access token을 첨부해서 request를 서버에 전송함으로서 매번 로그인 해도 되지 않도록 한다.

- 인증은 왜 필요할까요?

• 우리 서비스를 누가 쓰며 어떻게 사용하고 있는지 추적이 가능하도록 하기 위해 필요합니다.
  
• 인증에 필요한 것은 무엇이 있을까요?
  • ID, Email, Password
  • 가장 중요한 것은 Password
• 비밀번호는 어떻게 관리해야 하는가?
  • Database에 저장 시 개인정보를 해싱하여 복원할 수 없도록 함.
  • 통신 시 개인 정보를 주고 받을 때 SSL을 적용하여 암호화 (HTTPS)

단방향 해쉬란?

• 본래 해쉬 함수는 자료구조에서 빠른 자료의 검색, 데이터의 위변조 체크를 위해서 쓰이지만, 복원이 불가능한 단방향 해쉬함수는 암호화적 용도로 사용합니다.

• (MD5, SHA-1)(둘은 보안 취약), SHA-256등이 있습니다.

• 단방향 해쉬 함수도 몇가지 취약점이 있다.
  - Rainbow table attack - 미리 해쉬값들을 계산해 놓은 테이블을 Rainbow table이라고 한다.
  - 해시 함수는 원래 패스워드를 저장하기 위해서 설계된 것이 아니라 짧은 시간에 데이터를 검색하기 위해 설계된 것이다 (Remember Set?). 그렇기 때문에 해시 함수는 본래 처리 속도가 최대한 빠르도록 설계되었다. 이러한 속성 때문에 공격자는 매우 빠른 속도로 임의의 문자열의 다이제스트와 해킹할 대상의 다이제스트를 비교할 수 있다(MD5를 사용한 경우 일반적인 장비를 이용하여 1초당 56억 개의 다이제스트를 대입할 수 있다). 이런 방식으로 패스워드를 추측하면 패스워드가 충분히 길거나 복잡하지 않은 경우에는 그리 긴 시간이 걸리지 않는다 (대부분 사용자의 패스워드는 길거나 복잡하지 않을 뿐 아니라, 동일한 패스워드를 사용하는 경우도 많다).

• 단방향 해쉬 함수의 취약점들을 보안하기 위해 일반적으로 2가지 보완점들이 사용된다.
  

1. Salting

• 실제 비밀번호 이외에 추가적으로 랜덤 데이터를 더해서 해시값을 계산하는 방법.
• 단순해쉬값이 해킹에 쉽게 노출되기 때문에 salting이라는 아이디어가 생겨났습니다.
• 입력한 비밀번호와 임의로 생성한 문자열(Salt)를 합쳐서 해싱해서 이 해시값을 저장하는 방법입니다.
• 물론 이때에 비교를 위해 해시값과 소금(Salt)값을 같이 저정해야합니다.
• 여기에 해커가 패스워드 무작위 대입을 통해 해시값을 계산하는데 필요한 시간을 대폭 늘리기 위해 salting 및 해싱을 여러번 반복해서 원본 값을 유츄하기 어렵게 만드는 것이 key stretching입니다.
  

2. Key Stretching**

• 단방향 해쉬값을 계산 한 후 그 해쉬값을 또 해쉬 하고, 또 이를 반복하는 것을 말한다.
• 최근에는 일반적인 장비로 1초에 50억 개 이상의 다이제스트를 비교할 수 있지만, 키 스트레칭을 적용하여 동일한 장비에서 1초에 5번 정도만 비교할 수 있게 한다. GPU(Graphics Processing Unit)를 사용하더라도 수백에서 수천 번 정도만 비교할 수 있다. 50억 번과는 비교할 수도 없을 정도로 적은 횟수다. 앞으로 컴퓨터 성능이 더 향상되면 몇 번의 반복을 추가하여 보완할 수 있다.

Bcrypt

• Salting & Key Stretching 대표적 라이브러리
• 다영한 언어를 지원하고 있으며, 사용이 간편하여 쉽게 적용이 가능합니다.
• bcrypt는 hash 결과 갑셍 소금값과 해시값 및 반복횟수를 같이 보관하기 때문에 비밀번호 해싱을 적용하는데 있어 DB 설계를 복잡하게 할 필요가 없습니다.
• 해싱된 결과 값(Digest)
  

인가(Authorization)

인가는 무엇일까요?

• 해당 유저가 request에 해당하는 권한이 있는지 확인하는 절차
• Http의 특징은 무엇일까요?
  - 바로 request/ respense 요청과 응답
  - stateless한 성질(저장하지 않는 성질)
  

서버는 사용자가 로그인 했을 경우, 로그인 했다는 것을 어떻게 알 수 있을까요?

• 바로 headers에 메타데이터를 보내서 확인합니다.
  
• 이 메타정보를 바로 JSON Web Token 일명 ‘JWT’ 라고 합니다.

JSON Web Token

헤더(header).내용(payload).서명(signature)

헤더(header)

• 토큰의 타입과 해시 알고리즘 정보가 들어갑니다.
• 헤더의 내용은 BASE64 방식으로 인코딩해서 JWT의 가장 첫 부분에 기록됩니다.

내용(payload)

• 만료시간을 나타내는 exp와 같이 미리 정의된 집합인 Registered Claim
• 공개용 정보 전달을 목적으로 하는 Public Claim
• 그리고 클라이언트와 서버간 협의하에 사용하는 Private Claim
• 위의 세 가지 요소를 조합하여 작성한뒤 BASE64 인코딩하여 두번째 요소로 위치합니다.
• 예시 - {”user-id” : 1, “exp”: 1539517391 }

서명(signature)

• JWT가 원본 그대로라는 것을 확인할 때 사용하는 부분입니다.
• 시그니쳐는 BASE64URL 인코드된 header와 payload 그리고 JWT secret(별도 생성)을 헤더에 지정된 암호 알고리즘으로 암호화하여 전송합니다.(복호화 가능)
• 프론트엔드가 JWT를 백엔드 API 서버로 전송하면 서버에서는 전송받은 JWT의 서명부분을 복호화하여 서버에서 생성한 JWT가 맞는지 확인합니다.
• 마치 계약서의 위변조를 막기위해 서로 사인하는 것과 같다고 보시면 됩니다.
• 주의할 점은 header와 payload는 BASE64 인코딩한 것이므로(암호화 아님) 누구나 원본을 볼 수 있으니 개인정보를 담아서는 안됩니다.

Authorization 절차

1. Authentication 절차를 통해 access token을 생성한다. access token에는 유저 정보를 확인할 수 있는 정보가 들어가 있어야 한다 (예를 들어 user id).
2. 유저가 request를 보낼때 access token을 첨부해서 보낸다.
3. 서버에서는 유저가 보낸 access token을 복호화 한다.
4. 복호화된 데이터를 통해 user id를 얻는다.
5. user id를 사용해서 database에서 해당 유저의 권한(permission)을 확인하다.
6. 유저가 충분한 권한을 가지고 있으면 해당 요청을 처리한다.
7. 유저가 권한을 가지고 있지 않으면 Unauthorized Response(401) 혹은 다른 에러 코드를 보낸다.

참고 및 출처
위코드 강의