인증 Authentication

• 유저의 identification을 확인하는 절차, 즉 유저의 아이디와 비밀번호를 확인하는 절차이다.
• 인증을 하기 위해서는 먼저 유저의 아이디와 비밀번호를 생성할 수 있는 기능도 필요하다.

로그인 절차

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

유저 비밀번호 암호화

• 유저의 비밀번호는 절대로 비밀번호 그대로 DB에 저장하지 않는다.
  • DB가 해킹을 당하면 유저의 비밀번호가 그대로 노출된다.
  • 외부 해킹이 아니더라도 내부 개발자나 인력이 유저의 비밀번호를 볼 수 있다.
• 유저의 비밀번호는 반드시 암호화해서 저장해야 한다.
• 비밀번호 암호에는 단방향 해쉬 함수가 일반적으로 쓰인다.

단방향 해시 함수 (one-way hash function)

단방향 해시 함수는 원본 메시지를 변환하여 암호화된 메시지인 다이제스트(digest)를 생성한다. 원본 메시지를 알면 암호화된 메시지를 구하기는 쉽지만 암호화된 메시지로는 원본 메시지를 구할 수 없어서 단방향성(one-way)라고 한다.

예를 들어, "test password"를 hash256이라는 해시 함수를 사용하면 0b47c69b1033498d5f33f5f7d97bb6a3126134751629f4d0185c115db44c094e 값이 나온다.

만일 "test password2"를 hash256 해시 함수를 사용하면 d34b32af5c7bc7f54153e2fdddf251550e7011e846b465e64207e8ccda4c1aeb 값이 나온다. 실제 비밀번호는 비슷하지만 해시 함수 값은 완전히 다르다. 이러한 효과를 avalance라고 하는데 비밀번호 해시 값을 해킹하기 어렵게 만드는 하나의 요소이다.

Bcyrpt

• 단방향 해시 함수도 몇가지 취약점이 있다.
  • Rainbow table attack : 미리 해시 값들을 계산해 놓은 테이블
  • 해시 함수는 원래 패스워드를 저장하기 위해서 설계된 것이 아니라 짧은 시간에 데이터를 검색하기 위해 설계된 것이다. 그렇기 때문에 해시함수는 본래 처리 속도가 최대한 빠르도록 설계되었다. 이러한 속성 때문에 공격자는 매우 빠른 속도로 임의의 문자열의 다이제스트와 해킹할 대상의 다이제스트를 비교할 수 있다. (MD5를 사용한 경우 일반적인 장비를 이용하여 1초당 56억 개의 다이제스트를 대입할 수 있다.) 이런 방식으로 패스워드를 추측하면 패스워드가 충분히 길거나 복잡하지 않은 경우에는 그리 긴 시간이 걸리지 않는다.
• 단방향 해시 함수를 보안하기 위한 두가지 방법
  • Salting : 실제 비밀번호 이외에 추가적으로 랜덤 데이터를 더해서 해시 값을 계산하는 방법
  • Key Stretching : 단방향 해시값을 계산한 후 그 해시 값을 또 해시하고 또 하고.. 반복하는 것을 말한다.
    최근에는 일반적인 장비로 1초에 50억 개 이상의 다이제스트를 비교할 수 있지만, 키 스트레칭을 적용하여 동일한 장비에서 1초에 5번 정도만 비교할 수 있게 한다. GPU(Graphics Processing Unit)를 사용하더라도 수백에서 수천 번 정도만 비교할 수 있다. 50억 번과는 비교할 수 없을 정도록 적은 횟수다. 앞으로 컴퓨터 성능이 더 향상되면 몇 번의 반복을 추가하여 보완할 수 있다.

Salting과 Key Stretching을 구현한 해시 함수 중 가장 널리 사용되는 것이 bcrypt이다. bcrypt는 처음부터 비밀번호를 단방향 암호화하기 위해 만들어진 해시함수이다.

JWT (JSON Web Tokens)

유저가 로그인을 성공한 후에는 access token이라고 하는 암호화된 유저 정보를 첨부해서 클라이언트에게 전송한다. 즉, 프론트에서 ID/PW를 서버(백엔드)로 넘겨주면 백엔드가 DB에서 ID/PW를 비교하고, 확인 후 맞으면 다시 프론트에게 access token을 전달하는 것이다.

이 토큰은 클라이언트의 브라우저에 저장이 되어 보관되다가 마이페이지와 같이 인증이 필요한 곳에서 프론트가 다시 access token을 백엔드에게 넘겨주면 백엔드는 유저를 확인하고 마이페이지에 해당하는 정보를 다시 전달하게 된다.

• 유저 로그인

POST /auth HTTP/1.1
Host: localhost:5000
Content-Type: application/json

{
    "username": "joe",
    "password": "pass"
}

• access token

HTTP/1.1 200 OK
Content-Type: application/json

{
    "access_token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpZGVudGl0eSI6MSwiaWF0IjoxNDQ0OTE3NjQwLCJuYmYiOjE0NDQ5MTc2NDAsImV4cCI6MTQ0NDkxNzk0MH0.KPmI6WSjRjlpzecPvs3q_T3cJQvAgJvaQAPtk1abC_E"
    // access tocken은 위와 같이 알 수 없는 string으로 되어있다.
}

그러면 서버에서는 access token을 복호화해서 해당 유저 정보를 얻게 된다. 복호화하여 얻은 유저 아이디를 통해 해당 유저가 누군지 알 수 있다.

이러한 절차의 목적은 해당 유저가 매번 로그인할 필요가 없도록 하는 것이다. access token을 생성하는 방법에는 여러가지가 있으나 그 중 가장 널리 사용되는 기술 중 하나가 JWT이다. JWT는 말 그대로 유저 정보를 담은 JSON 데이터를 암호화해서 클라이언트와 서버 간에 주고 받는 것이다.

왜 아이디와 패스워드 대신에 Access Token을 사용할까?

무거운 bcrypt를 사용할 필요없이 간단한 해시로 작동한다. 실제 아이디나 패스워드가 쿠키와 같은 클라이언트의 스토리지에 저장되지 않는다. 또한 토큰은 특정 서버에서만 적용될 수 있기 때문에 다른 사이트에서 다시 사용될 수 없다.

인가 (Authorization)

• 유저가 요청하는 request를 실행할 수 있는 권한이 있는 유저인가를 확인하는 절차이다. 예를 들어, 해당 유저는 고객 정보를 볼 수 있지만 수정할 수 없다 등.
• 인가 역시 JWT를 통해 구현될 수 있다. access token을 통해 해당 유저 정보를 얻을 수 있음으로 해당 유저가 가지고 있는 권한도 확인할 수 있다.

Authorization 절차

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