Bcrypt & Jsonwebtoken

Bcrypt & Jsonwebtoken 🙀

“보안 시스템은 가장 약한 연결 고리만큼만 강하다.”

특정부분의 보안이 아무리 강하다고 하더라도 다른부분에서 보안이 뚫려버리면 의미가 없다.

따라서 보안 시스템의 안정성은 ‘강한 부분이 얼마나 강한가’보다는 ‘약한 부분이 얼마나 약한가’에 따라서 좌우된다.

---

단방향 해시 함수

단방향 해시 함수 : 수학적인 연산을 통해 원본 메시지를 변환하여 암호화된 메시지인 다이제스트를 생성한다.. 원본 메시지를 알면 암호화된 메시지를 구하기는 쉽지만 암호화된 메시지로는 원본 메시지를 구할 수 없어야 하며 이를 '단방향성'이라고 한다.

예를 들면 “abcd”라는 문자열은 해시알고리즘에 의해 “adasfuaokfa32423823joegnsvd324refwdoiepoht23n34” 같은 문자열로 인코딩될 수 있다.

위의 값을 저장하면 사용자의 패스워드를 직접 저장하는 위험을 피할 수 있다. 그리고 사용자가 로그인할 때 패스워드를 입력하면, 이를 해시한 값을 저장된 값과 비교하여 일치 여부를 확인할 수 있다.

이 특징을 avalanche 효과라고 하며, 사용자의 원본 패스워드를 추론하기 어렵게 만드는 중요한 요소이다.

---

단방향 해시 함수의 문제점

동일한 메시지가 언제나 동일한 다이제스트를 갖는다면, 공격자가 전처리(pre-computing)된 다이제스트를 가능한 한 많이 확보한 다음 이를 탈취한 다이제스트와 비교해 원본 메시지를 찾아내거나 동일한 효과의 메시지를 찾을 수 있다.

이와 같은 다이제스트 목록을 레인보우 테이블(rainbow table)이라 하고, 이와 같은 공격 방식을 레인보우 공격(rainbow attack)이라 한다. 게다가 다른 사용자의 패스워드가 같으면 다이제스트도 같으므로 한꺼번에 모두 정보가 탈취될 수 있다.

---

단방향 해시 함수 보완하기

솔팅(salting) : 단방향 해시 함수에서 다이제스트를 생성할 때 추가되는 바이트 단위의 임의의 문자열이다. 그리고 이 원본 메시지에 문자열을 추가하여 다이제스를 생성하는 것을 솔팅(salting)이라 한다. 예를 들어 다음과 같이 "abcd"라는 문자열에 솔트인 "8zff4fgflgfd93fgdl4fgdgf4mlf45p1"를 추가해 다이제스트를 생성할 수 있다.

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

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

키 스트레칭(key stretching) : 입력한 패스워드의 다이제스트를 생성하고, 생성된 다이제스트를 입력 값으로 하여 다이제스트를 생성하고, 또 이를 반복하는 방법으로 다이제스트를 생성할 수도 있다. 이렇게 하면 입력한 패스워드를 동일한 횟수만큼 해시해야만 입력한 패스워드의 일치 여부를 확인할 수 있다. 이것이 기본적인 키 스트레칭 과정이다.

---

bcrypt

bcrypt : 애초부터 패스워드 저장을 목적으로 설계되었다. Niels Provos와 David Mazières가 1999년 발표했고 현재까지 사용되는 가장 강력한 해시 메커니즘 중 하나이다. bcrypt는 입력 값으로 72 bytes character를 사용해야 하는 제약이 있다.

# terminal
$ npm install bcrypt

import bcrypt from 'bcrypt';

const salt = bcrypt.genSaltSync(10);
const hash = bcrypt.hashSync(password, salt);

같은 패스워드라해도 솔트부분이 매번 바뀌는것을 볼 수 있다.

bcrypt의 hashing의 경우에 CPU의 영향을 많이 받는데, sync로 사용하게 되면 이벤트 루프에서 block 당할 수 있기 때문이다. 그래서 간단하게 스크립트를 이용해서 사용할 때는 괜찮지만, 서버에서 사용할 땐 async 모드를 권장하고 있다.

const signIn = async (password) => {

const comparePw = await bcrypt.compare(password, users.password)

if(!coparePw) throw new Error('id , pw가 맞지 않습니다.');

}

---

JWT

JWT(Json Web Token) : 각 객체 사이에서 속성 정보을 JSON 데이터 구조로 표현하고 암호화를 통해 정보를 전달하는 Token의 대표

JWT를 사용하는 가장 흔한 시나리오.

유저가 로그인을 하면, 서버는 유저의 정보에 기반한 토큰을 발급하여 유저에게 전달.

그 후, 유저가 서버에 요청을 할 때마다 JWT를 포함하여 전달.

서버가 클라이언트에게서 요청을 받을 때마다, 해당 토큰이 유효하고 인증됐는지 검증을 하고, 유저가 요청한 작업에 권한이 있는지 확인하여 작업을 처리.

즉, 서버 측에서는 유저의 세션을 유지할 필요가 없음.

유저가 로그인되어있는지 안되어있는지 신경 쓸 필요가 없고, 유저가 요청을 했을 때 토큰만 확인하면 되니, 세션 관리가 필요 없어서 서버 자원을 많이 아낄 수 있음.

---

JMT 구조

Header : 타입(JWT)과 알고리즘(BASE64 같은)을 담는다.

Payload : 보통 유저정보(id같은)와 만료기간이 객체형으로 담긴다.

Signature : header, payload를 인코딩 한 값을 합친뒤 SECRET_KEY로 해쉬한다.( 환경변수로 설정 )

---

사용법

# npm install jsonwebtoken

JWT_SECRET=JwTsEcReTkEyOrHaShInG

.evn에서 환경변수로 시크릿키 설정

const jwt = require('jsonwebtoken');

  const token = jwt.sign(
    {
      id: users.id,
    },
    process.env.JWT_SECRET,
    {
      expiresIn: '60m', // 유효 시간은 60분
    }
  );

sign()

1번째 인자 : payload 즉, 보낼내용. (중요한 정보는 담지않도록 할것)

2번째 인자 : 비밀키 ( gitignore에 숨길것을 권장 )

3번째 인자 : 토큰정보 ( 주로 유효기간 )

4번째 인자 : 콜백함수 ( 사용하지않으면 동기식으로 처리된다. )

const verifyToken = (token) => {
  try {
    return jwt.verify(token, process.env.JWT_SECRET);
  } catch (err) {
    return null;
  }
};

const Authentication = (req, res, next) => {
  const token = req.cookies.user; // token가져오기

  const vaildToken = verifyToken(token);

  if (vaildToken) {
    req.userId = vaildToken.id;
    next();
  } else {
    res.status(400).send('토큰이 유효하지 않습니다.');
    return;
  }
};

주로 인증에 사용된다.