🍟 해싱

해시 테이블에서 다루었던 적이 있는 Hash!

키(Key) 값을 해시 함수(Hash Function)라는 수식에 대입시켜 계산한 후 나온 결과를 주소로 사용하여 바로 값(Value)에 접근하게 할 수 하는 방법이다.

인증에서의 해싱이란 결국 어떤 값에 "임의의 연산"을 적용해 다른 값으로 변환, 즉 암호화하는 과정을 말하는 것이라 할 수 있다.

🛠 해싱 알고리즘이 갖춰야 할 조건

1) 모든 값에 대해 해시값을 계산하는데 오래 걸리지 않아야 한다.
2) 최대한 해시 값을 피해야 하며, 모든 값은 고유한 해시 값을 가진다.
3) 아주 작은 단위의 변경이라도 완전히 다른 해시 값을 가져야 한다.

🧂 Salt

그러나 사실 완벽한 해싱 알고리즘, 완벽한 암호화란 없다. 물론 해싱함수는 역함수가 존재하지 않는 함수로 만드는 것이 일반적이지만, 모든 경우의 수를 기록해놓고 추적하는 것까지 막을 수는 없다. 해시함수를 사용하여 만들 수 있는 값들을 대량으로 저장해놓은 표인 레인보우 테이블이란 것도 존재한다...!

그래서! 원본값에 임의로 약속된 별도의 문자열을 추가해 기존 해시 값과 전혀 다른 해시값을 반환해 알고리즘이 노출되더라도 원본값을 보호한다. 이 때 추가하는 별도의 값을 salt라고 한다!

⛔️ Salt에 대해 주의해야 할 사항

salt는 재사용해서는 안 되며, 사용자 계정을 생성하고 비밀번호를 변경할 때마다 새로운 임의의 salt를 사용해 해싱해야 한다. 또, salt는 당연히 DB 유저 테이블에 같이 저장한다!

🥠 쿠키

처음에 쿠키를 학습할 때, 인증과 엮어서 학습했어서 쿠키를 세션, 토큰과 비슷하게 인증 방식 자체로 이해했었다. 그러나 엄밀히 말하면 쿠키는 인증 방식이라기보다는 서버에서 클라이언트에 데이터를 저장하는 방법 중 하나이다. 다만 인증 과정에 활용되는 것!

HTTP 쿠키(웹 쿠키, 브라우저 쿠키)는 서버가 사용자의 웹 브라우저에 전송하는 작은 데이터 조각입니다. 브라우저는 그 데이터 조각들을 저장해 놓았다가, 동일한 서버에 재 요청 시 저장된 데이터를 함께 전송합니다. 쿠키는 두 요청이 동일한 브라우저에서 들어왔는지 아닌지를 판단할 때 주로 사용합니다. 이를 이용하면 사용자의 로그인 상태를 유지할 수 있습니다. 상태가 없는(stateless) HTTP 프로토콜에서 상태 정보를 기억시켜주기 때문입니다.

모쪼록 쿠키를 활용하면 서버는 클라이언트에 데이터를 전달해 저장할 수 있고, 또 해당 정보를 다시 가져올 수도 있다! (또한 쿠키는 따로 삭제하지 않으면 계속해서 보존된다.) 그러나 당연하게도 아무 때나 서버가 클라이언트에서 정보를 가져올 수 있는 것은 아니다. 이 조건들을 나타낸 것들이 바로 쿠키옵션이다!

🍫 쿠키 옵션

// example
    cookie: {
      domain: 'localhost',
      path: '/',
      maxAge: 24 * 6 * 60 * 10000,
      sameSite: 'none',
      httpOnly: true,
      secure: true,
    },

• Domain: 쿠키의 도메인 옵션과 서버의 도메인이 일치해야만 쿠키를 전송할 수 있다.
• Path: 쿠키의 path 옵션과 서버의 세부경로가 일치하는 경우 쿠키를 전송할 수 있다.
• MaxAge or Expires: 쿠키의 유효기간 설정
• HttpOnly: 스크립트의 쿠키접근 가능 여부 결정, false로 설정되어 있는 경우 스크립트태그로 쿠키에 접근 가능하다. (XSS 공격에 취약하므로, 민감한 개인정보는 담지 않는 것이 좋다.)
• Secure: 해당 옵션이 true로 설정되어 있는 경우, https 프로토콜에서만 쿠키 전송 가능하다.
• SameSite: CORS 요청의 경우, 옵션 및 메서드에 따라 쿠키 전송 여부 결정. (Lax-'GET' 메소드에 대해서만 쿠키 전송 가능, Strict-CrossOrigin이 아닌 sameSite에 대해서만 쿠키 전송 가능, None-항상 쿠키전송 가능하지만 쿠키옵션중 secure 옵션이 활성화되어야 함)

쿠키를 어디에 활용할 것이냐!

세션 관리(Session management)

서버에 저장해야 할 로그인, 장바구니, 게임 스코어 등의 정보 관리

개인화

사용자 선호, 테마 등의 세팅

트래킹

사용자 행동을 기록하고 분석하는 용도

🎟 세션

쿠키는 사실 그 자체로 인증 수단은 아니라는 사실을 살펴보았다. 게다가 클라이언트에 정보들을 저장하는데 이는 보안에 그리 강력한 선택이 아니다! 이에 대한 대안으로 우리는 세션 기반 인증을 알아볼 것이다!

쿠키가 클라이언트에 데이터를 저장하는 것과 달리 세션 기반 인증에서는 데이터들을 서버에 안전하게 저장한다! 세션 스토리지에 정보들을 저장하고 대신 클라이언트에는 세션 id만을 전달해주는 것이다! 명확히 따지면 사용자가 인증에 성공한 상태가 세션에 해당하고, 세션이 활성화되면 세션아이디가 발급되고, 이 세션 성공을 증명할 수단으로 클라이언트는 세션아이디를 사용하게 되는 것이다. 그리고 쿠키에는 이 id만 저장을 해주는 것이다!

세션 스토리지를 저장하는 방식은 다양한데, 1) 서버 자체에 저장을 할 수도 있고, 2) 파일로 저장을 할 수도 있고, 3) DB에 저장을 할 수도 있다. 1)의 경우 서버가 종료되면 정보들이 모두 사라진다는 취약점이 존재하며, 2)의 경우 동시적 수정이 불가하다는 단점이 존재한다!

Session의 기본 로직

클라이언트는 아이디와 비밀번호를 요청 바디에 담아 로그인 포스트 요청을 보낸다

    axios
      .post(
        "https://localhost:4000/users/login",
        {
          userId: this.state.username,
          password: this.state.password,
        },
        {
          "Content-Type": "application/json",
          withCredentials: true,
        }
      )

여기서 잠깐 withCredentials에 대해 짚고 넘어가자! 기본적으로 withCredentials는 CORS 옵션이다. 같은 origin에서 http통신을 하는 경우 알아서 cookie가 request header에 들어간다. 하지만 origin이 다를 경우는 그렇지 않다. 수동으로 쿠키를 헤더에 넣어주어야 한다. 이때 필요한 것이 클라이언트에서는 withCredentials: true, 서버에서는 Access-Control-Allow-Credentials : true이다!

로그인 요청을 받은 서버는 세션을 활성화한다!

      req.session.save(function () {
        req.session.userId = userInfo.userId;
        res.json({ data: userInfo, message: "ok" });
      });

Session.save(callback)

해당 메서드는 세션을 다시 저장소에 저장하고, 저장소의 내용을 메모리의 내용으로 바꾼다. 세션을 스토어에 저장하고 나면 callback으로 넘겨준 함수가 실행된다. 이 메서드를 쓰지 않으면, 데이터를 session store에 저장하는 것보다 redirect가 먼저 실행되어 로그인 상태가 유지되지 않는 버그가 발생할 수 있다!

서버는 이후에 요청을 받을 시 session을 확인해 인증과정을 거친다.

    if (!req.session.userId) {
      res.status(400).send({ data: null, message: "not authorized" });
    } else {
      const result = await Users.findOne({
        where: { userId: req.session.userId },
      }).catch((err) => res.json(err));

      res.status(200).json({ data: result, message: "ok" });
    }

쿠키와 세션, 전격 비교!

• 저장은 어디에? 쿠키는 클라이언트, 세션은 서버
• 장점은? 쿠키는 서버에 부담 안 줌, 세션은 신뢰할 만한 유저인지 서버에서 추가로 확인 가능! (더 안전함)
• 단점은? 쿠키는 그 자체로는 인증이 아님, 세션은 분산에 불리함

참고문서

• 개발자 키니 블로그