📒 목차

📌 로그인 프로세스 이해
📌 JWT 토큰과 조작 불가능성 이해
📌 암호화(양방향 암호화)와 해싱(단방향 암호화)
📌 Hash(단방향 암호화)
📌 Key Stretching & Salt

📌 로그인 프로세스 이해

✅ 첫 번째 로그인 역사 (쿠키 / 세션 로그인)

우리가 이메일과 비밀번호를 사용하여 로그인을 한다고 가정해보자. 로그인 버튼을 누르게 되면, 백엔드 서버로 loginAPI 요청이 날라가게 되고, 백엔드에서는 해당 유저를 Backend session에 저장한다.

그 후, session ID를 부여하여 브라우저로 보내준다.

이때, session ID는 로그인을 해야지만 사용할 수 있는 서비스에 사용된다. 예를 들어, 포인트충전API, 프로필 수정API과 같은 서비스가 있다.

좀 더, 구체적으로 설명하자면, 우리가 로그인하여 포인트를 충전한다고 해보자.

백엔드에서는 신원이 확인되지 않은 유저가 포인트를 충전하는 것을 허용할 수 없기 때문에 유저를 식별하기 위해 충전을 요청한 유저가 session ID를 넣어서 포인트 충전 요청이 들어오도록 한다.

그 후, 백엔드에서는 session ID를 확인하여 포인트를 데이터베이스에 저장하고 만약, 신원이 확인되지 않았다면 에러 메시지를 반환해준다.

하지만, 이러한 방식에는 문제점이 존재한다.

유저의 정보를 백엔드 서버로 받게 되니, 한번에 여러명의 정보를 받는데 한계점이 있다.
즉, 접속자가 많아질수록 백엔드 서버의 메모리가 부족해지고, 서버에 문제가 생기게 된다.

이러한 문제를 해결하기 위해 백엔드 컴퓨터를 scale-up하게 되었다.

scale up
scale-up이란 CPU 또는 Memory 등을 업그레이드하여 컴퓨터의 성능을 올려주는 것이다.

✅ 두 번째 로그인 역사 (쿠키 / 세션 로그인)

백엔드 컴퓨터의 성능을 올리더라도 접속자 수가 많아지게 되면 여전히 서버의 부하를 초래하게 되었다.

따라서 두 번째 방법으로는 백엔드 컴퓨터를 복사하였다.
즉, 유저의 정보가 담긴 백엔드 컴퓨터를 여러 대로 복사해 서버의 부하를 분산하는 것이다.

하지만 이 방법 역시, 문제가 있었는데, 컴퓨터를 복사할 때, session 정보까지 복사하지 않아 유저의 로그인 정보가 없다는 것이다.

결국, 동일한 유저 정보에 대해 모든 백엔드 컴퓨터에 저장하기 때문에 서버가 터지는 문제는 여전히 해결하지 못했다.

✅ 세 번째 로그인 역사 (테이블 파티셔닝 이해 - 수평(샤딩)과 수직)

세 번째 방법은 두 번째 방법의 문제를 보완한 방법이며, 현재 가장 많이 사용되고 있는 방법이다.

로그인 정보를 백엔드 세션에 저장하는 것이 아니라 DB에 저장하는 것이다.

DB를 나누는 2가지 방법
1. 수직으로 나누는 수직파티셔닝
2. 수평으로 나누는 수평파티셔닝(샤딩)

따라서 이제는 API를 요청할 때, 어떤 백엔드 컴퓨터에 접속해도 똑같은 요청처리와 응답이 이루어지게 되었다. 또한 수평 파티셔닝을 통해 DB를 나누어 저장하기 때문에 DB의 부하까지 분산할 수 있다.

DB에 저장할때는, 메모리 기반 세션 방식에서 디스크 기반의 토큰 방식으로 바뀌게 되었다.

로그인을 할때, 토큰을 브라우저에 전달하고 브라우저는 저장공간에 토큰을 저장하고 어떠한 행동을 할때 토큰을 같이 보내어 사용자가 누군지 식별한다.

하지만 여기서 문제가 발생하는데, 로그인을 할때마다 데이터베이스에서 해당 유저를 파악해야 하는 문제가 있다.
왜냐하면, 데이터베이스에서 데이터를 꺼내오는 속도가 느리기 때문이다.

따라서 이러한 문제를 해결하기 위해 Redis라는 데이터베이스에 저장하여 속도 문제를 해결한다.

Redis를 사용하면 컴퓨터가 꺼졌을 때, 데이터가 날아가는 단점이 있지만 속도가 빠른 장점이 있다.

📌 JWT 토큰과 조작 불가능성 이해

✅ 네 번째 로그인 역사

현재 가장 많이 쓰이는 방법 중 하나로 JWT 토큰 방식이다.

JWT 토큰은 유저 정보를 담은 객체를 암호화를 통해 문자열로 만들어 암호화된 키(accessToken)를 브라우저로 전달해 준다.

백엔드는 브라우저에서 받은 암호화 키를 복호화하여 유저를 식별한 후, 접근이 가능하도록 한다.

JWT 토큰에는 해당 토큰이 발급 받아온 서버에서 정상적으로 발급을 받았다는 증명을하는 signature를 가지고 있다. 따라서 사용자의 정보를 DB를 열어보지 않고도 식별할 수 있다.

JWT 토큰의 구성
1. header : 토큰의 타입, 암호화시 사용한 알고리즘 정보
2. payload : 토큰 발행정보(누구인지, 언제 발행되었는지, 언제 만료될 것 인지)
3. signature : 토큰의 비밀번호

✅ 인증 (Authentication)

로그인을 통해 accessToken을 받아오는 과정을 의미한다.
받아온 accessToken에는 유저가 로그인 한 기록이 저장되어 있다.

따라서 유저정보를 확인해야 하는 API를 사용할 때, accessToken을 첨부해서 요청해야지 유저정보를 확인 후 해당 API를 사용할 수 있다.

✅ 인증 (Authentication)

앞서 받아온 accessToken을 복호화 하여 유저정보를 검증하는 과정을 인가라고 한다.

✅ JWT의 문제점

누군가 토크을 가져간다면 토큰의 정보를 알수 있다.
즉, JWT토큰은 암호화는 했지만 누구든 열어볼 수 있다는 문제가 있다.
따라서, 중요한 정보는 JWT 토근에 저장해서는 안된다.

암호화와 복호화
1. Encoded : 암호화

2. decoded : 복호화(암호를 푸는 것)

하지만, 누구든지 복호화하여 열어 볼 수는 있지만, 토큰의 내용을 조작할 수는 없다.
토큰을 생성할 때 signature(토큰의 비밀번호)를 생성하여 사용하게 되는데, 이 비밀번호를 누구나 아는 것은 아니다. 따라서 백엔드에서 signature를 통해 토큰 조작 여부를 알 수 있다.

📌 암호화(양방향 암호화)와 해싱(단방향 암호화)

일반적으로 사람들이 비밀번호를 만들 때, 모든 사이트에서 비밀번호를 다르게 설정하는 경우는 많지 않다. 따라서 데이터베이스에 비밀번호를 저장할 때, 비밀번호 그대로 저장을 하게되면, 해킹이 발생했을 때, 해당 페이지 뿐만 아니라 다른 사이트까지 추가적인 해킹 위험이 발생하게 된다.

따라서, 데이터베이스에 비밀번호를 저장할 때는 비밀번호를 암호화하여 저장하게 된다.

하지만 암호화에 사용된 키를 사용하면 데이터를 복호화 할 수도 있다. 따라서 완전한 암호화가 되지 않는 문제를 해결하기 위해 해싱이 나타나게 되었다.

✅ 암호화의 종류

• 양방향 암호화 : 암호화와 복호화과정을 통해 송 ・ 수신 간 주고받는 메시지를 안전하게 암호화하고 평문으로 복호화하는 과정.
• 단방향 암호화 : 해싱(Hashing)을 이용한 암호화 방식으로 양방향과는 다른 개념으로, 평문을 암호문으로 암호화는 가능하지만 암호문을 평문으로 복호화 하는 것은 불가능.

📌 Hash(단방향 암호화)

해시는 원본 데이터를 매핑시켜 완전히 다른 암호화된 데이터로 변환하는 것을 의미한다.

해시는 단방향 암호화이기 때문에 복호화 즉, 원본 데이터를 구할 수 없다.

Password 123456 을 해시 함수에 돌려서 다이제스트인 fs32a3xzz0 을 생성하고 해당 데이터를 DB 에 저장한다.

DB에 저장된 다이제스트가 설령 DB가 누출된다 하더라도 fs32a3xzz0 은 단방향으로 해싱 된 문자라 복호화 할 수가 없다.

📌 Key Stretching & Salt

어떠한 알고리즘 암호화를 통해 나온 값을 보고 그 값이 나올 수 있는 모든 경우를 스캔하는 레인보우 테이블을 이용하여 무작정 다 대입해 복호화 하는 경우가 존재하기 때문에 해시로만 변환한다고 해서 보안이 완벽한 것은 아니다.

✅ Key Stretching

Key Stretching(키-스트레칭)은 개발자가 횟수를 정해서 Hash 함수를 돌리는 방법으로 패스워드를 저장할 때 가장 쉽게 생각 할 수 있는 방법이다.

✅ Salt

여러 번 해시 함수를 돌리더라도 결국 몇 번 돌렸는지 횟수만 알게 된다면, 공격하는 입장에서 상징성 있는 대표 문자열들을 추려보면 충분히 공격이 가능하다.

또한 같은 비밀번호를 사용하는 사용자들이 있다면 하나의 결과를 갖고도 다수 사용자의 password 를 알아낼 수 있다.

따라서 이러한 문제를 방지하기 위해 도입한 것이 바로 솔트이다.

Salt(솔트)란 해시함수를 돌리기 전에 원문에 임의의 문자열을 덧붙이는 것을 말한다. 의미 그대로 원문에 임의의 문자열을 붙이는 의미의 소금친다(Salting)이라고 생각하면 된다.

🌈 오늘 하루

오늘은 회원가입에 사용되는 비밀번호가 데이터베이스에 저장될 때, 어떠한 부분을 고려해야 하는지에 대하여 학습하였다. 유저의 비밀번호는 보안과 관련된 민감한 정보이기 때문에 백엔드 입장에서 신중하고 철저하게 관리 되어야 한다. 오늘 배운 회원가입의 암호화를 통해 앞으로 만들어 나갈 로그인에 대한 학습을 미리 준비하는 단계라고 생각한다.