[CS/Network] 서버통신 인증&인가

서버단에서 이뤄지는 인증 & 인가를 정리해보려합니다.

인증과 인가

1. 인증, 인가 정의
2. 단방향 해쉬란?
3. salting & key stretching이란?
4. Bcrypt와 JWT

1. 인증 Authentication

인증은 유저의 identification을 확인하는 절차(유저의 아이디와 비밀번호를 확인하는 절차)

인증을 위해선 회원가입 기능 필요

 

1-1 로그인절차

유저 아이디 비번 생성 >> 유저 비번 암호화 DB저장 >>  유저 로그인(Id, Pw 입력 ) >> 입력된 Pw 암호화  >> DB 저장된 비밀번호와 비교 >> 일치 시 로그인 >> 로그인 성공시 유저에게 access token이 발행 >

*access token이 발행된 이후 고객은 인가가 필요한 페이지에선 Token을 서버에게 전송하므로 매번 로그인 하지 않아도 된다.

 

1-2 유저 비밀번호 암호화

유저에게 받은 비밀번호는 암호화하여 DB 저장  >> 암호화되어 DB해킹, 내부개발자도 비밀번호 그대로를 열람할 수 없다.

 

비밀번호 암호화

단방향 해쉬 함수(one-way hash function)가 일반적으로 쓰인다. 단순텍스트도 가능하나 법으로 막고있다.

• 단방향 해시 함수는 원본 메시지를 변환하여 암호화된 메시지인 다이제스트(digest)를 생성한다. 원본 메시지를 알면 암호화된 메시지를 구하기는 쉽지만 암호화된 메시지로는 원본 메시지를 구할 수 없어서 단방향성(one-way) 이라다고 한다. (다이제스트:해시함수를 통해 생성된 암호화된 메시지)
• 예를 들어, "test password"를 hash256이라는 해쉬 함수를 사용하면 0b47c69b1033498d5f33f5f7d97bb6a3126134751629f4d0185c115db44c094e 값이 나온다.
• 만일 "test password2"를 hash256 해쉬 함수를 사용하면d34b32af5c7bc7f54153e2fdddf251550e7011e846b465e64207e8ccda4c1aeb 값이 나온다. 실제 비밀번호는 비슷하지만 해쉬 함수 값은 완전히 틀린것을 볼 수 있다. 이러한 효과를 avalance라고 하는데 비밀번호 해쉬 값을 해킹을 어렵게 만드는 하나의 요소이다.

 

Bcrypt

단방향 해쉬 함수의 문제점

레인보우 공격(rainbow attack)  -인식가능성

레인보우 테이블(rainbow table)은 해시함수(MD-5, SHA-1, SHA-2 등)를 사용하여 만들어낼 수 있는 값들을 대량으로 저장한 표이다. 보통 해시함수를 이용하여 저장된 비밀번호로부터 원래의 비밀번호를 추출해 내는데 사용된다. 출처:해시넷

동일한 메시지가 언제나 동일한 다이제스트를 갖는다면 해커가 다이제스트를 다량 확보한 다음 탈취한 다이제스트와 비교해 원본 메시지를 찾아내거나 동일한 효과의 메시지를 찾을 수 있다. 이와 같은 다이제스트 목록을 레인보우 테이블(rainbow table)이라 한다. 게다가 다른 사용자의 패스워드가 같으면 다이제스트도 같으므로 한꺼번에 모두 정보가 탈취될 수 있다.

 

-속도

해시 함수는 원래 패스워드를 저장하기 위해서 설계된 것이 아니라 짧은 시간에 데이터를 검색하기 위해 설계된 것이다.

그렇기 때문에 해시 함수는 본래 처리 속도가 최대한 빠르도록 설계되었다. 이러한 속성 때문에 공격자는 매우 빠른 속도로 임의의 문자열의 다이제스트와 해킹할 대상의 다이제스트를 비교할 수 있다(MD5를 사용한 경우 일반적인 장비를 이용하여 1초당 56억 개의 다이제스트를 대입할 수 있다).

 

문제점 보완 기술

• Salting
  • 실제 비밀번호 이외에 추가적으로 랜덤 데이터를 더해서 해시값을 계산하는 방법.
  • 솔트(salt)는 데이터, 비밀번호, 통과암호를 해시 처리하는 단방향 함수의 추가 입력으로 사용되는 랜덤 데이터이다. 
  

이 방법을 적용하면, 공격자가 "happyburn"의 다이제스트를 알아내더라도 솔팅된 다이제스트를 대상으로 패스워드 일치 여부를 확인하기 어렵다. 또한 사용자별로 다른 솔트를 사용한다면 동일한 패스워드를 사용하는 사용자의 다이제스트가 다르게 생성되어 인식 가능성 문제가 크게 개선된다.

솔트와 패스워드의 다이제스트를 데이터베이스에 저장하고, 사용자가 로그인할 때 입력한 패스워드를 해시하여 일치 여부를 확인할 수 있다. 이 방법을 사용할 때에는 모든 패스워드가 고유의 솔트를 갖고 솔트의 길이는 32바이트 이상이어야 솔트와 다이제스트를 추측하기 어렵다.

 

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

Salting과 Key Stretching을 구현한 해쉬 함수중 가장 널리 사용되는 것이 bcrypt이다. bcrypt는 처음부터 비밀번호를 단방향 암호화 하기 위해 만들어진 해쉬함수이다. 실무에서 인증구현시 이러한 원리로 처음부터 하나하나 설계 하는 것이 아닌 공식적으로 검증된 암호시스템을  사용하는 것이 좋다. 이미 검증된 시스템을 사용하면, 암호화 시스템을 잘못 구현해서 발생하는 위험을 피할 수 있다.

 

JWT(JSON Web Tokens)

로그인에 성공하게 되면 암호화 된 유저정보인 Access Token을 첨부하여 서버에 요청한다.

 

유저로그인

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

{
    "username": "dududweb",
    "password": "aaaa1234"
}

access token

 

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

{
    "access_token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpZGVudGl0eSI6MSwiaWF0IjoxNDQ0OTE3NjQwLCJuYmYiOjE0NDQ5MTc2NDAsImV4cCI6MTQ0NDkxNzk0MH0.KPmI6WSjRjlpzecPvs3q_T3cJQvAgJvaQAPtk1abC_E"
}

서버에서 받은 암호화된 access token을 복호화하여 유저정보를 얻게 된다.(누군지 파악 가능하다.)

{
    user_id = 1 
}

 

이러한 짓은 유저가 편하라고 한다.(한번만 로그인하면 되기때문에)

 

access token을 생성하는 방법은 여러가지가 있는데, 그 중 가장 널리 사용되는 기술중 하나가 바로 JWT(JSON Web Tokens)이다.

: JSON 데이터를 암호화 해서 클라이언트와 서버간에 주고 받는 것

 

 

 

1. 인가(Authorization)

• Authorization은 유저가 요청하는 request를 실행할 수 있는 권한이 있는 유저인가를 확인하는 절차
• 해당 유저는 열람은 가능하나 편집은 불가하다 등
• Authroization도 JWT를 통해서 구현 될 수 있다.
  • access token을 통해 해당 유저 정보를 얻을 수 있음으로 해당 유저가 가지고 있는 권한(permission)도 확인 할 수 있다.

1-1. Authorization 절차

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

 

 

리뷰

 HTTP 

프론트에서 서버로 가는 길에선 암호화가 안되어있기 때문에 해커가 가로챈다면 무방비상태이다.

그래서 HTTPS , SSL, TLS 라는 개념이 적용되어야하는데 이부분을 추가로  공부, 정리해야겠다고 느꼈다.

 

 

 

참고출처:https://d2.naver.com/helloworld/318732