클라이언트 단에서 해싱해서 보낸다고 더 안전해지는 것은 아니다
https://www.palindrom615.dev/client-side-hashing-is-not-helping
- 비밀번호는 평문으로 전송하고 https를 사용한다. (https를 사용하고 있는지 꼭 확인할 것)
- 이미 비밀번호를 전송한 시점에서 사이트 운영자의 책임이 된다.(그 이후로는 법적인 영역)
세션 방식
- express session은 메모리에 저장하지만 이미 프로덕션 단계에 있기 때문에 이는 적합하지 않음(메모리 부족, 휘발성, 서버간 세션 공유 불가)
- Redis를 통해 세션을 저장
토큰 방식
- 로그인 유지 구현이 더 복잡할 수 있으나 새로운 db를 도입할 필요가 없고 서비스를 확장하는 것에도 어려움이 없음
- 세션 방식에 비해 공격에 취약함
선택 - 세션
https://www.youtube.com/watch?v=U6OcC0yq1CE&ab_channel=JanGoebel
- 일단 당장 엄청 많은 로그인 트래픽이 몰리지 않을 것이고 아직 세션조차 프로덕션 해보지 않은 상태에서 더 많은 공격 방법이 존재하는 JWT를 사용하는 것은 리스크만 증가한다고 생각한다.
로그인을 통해 할 수 있는 기능
- 즐겨찾기(시뮬레이션 저장, 검색어 저장)
- 데미지 사이클 게시 및 공략 게시하기
- 구독?
- 게시글 작성?
Redis
aws ec2 redis 설치
- ec2 생성, 보안그룹에서 TCP 포트 6379(redis용) 오픈
ubuntu에 redis 설치
https://www.digitalocean.com/community/tutorials/how-to-install-and-secure-redis-on-ubuntu-22-04 - 정말 잘 설명되어있다.
세션이 만료될 때 일어나는 일?
궁금증: 세션id를 저장하는 쿠키는 브라우저에서 만료기간을 설정하면 알아서 없어지지만 db에는 해당 세션과 관련된 정보가 남아있을 텐데(만료시간) 이를 주기적으로 지워줘야하나? 라는 의문이 생겼다.
redis는 TTL(Time To Live)기능을 가지고 있다. 즉 내가 데이터의 만료를 지정해놓으면 그 유효기간이 지나면 삭제된다는 것이다. 그럼 서버 개발 입장에서는 이 기능을 통해 세션의 만료를 쉽게 구현할 수 있다.
app.use(session({
store: new RedisStore({ client: redisClient }),
secret: 'your_secret_key',
resave: false,
saveUninitialized: false,
cookie: {
maxAge: 3600000, // 1 hour in milliseconds
secure: false,
},
}));
그래서 위의 express session예시로 쿠키의 maxAge를 지정하면 이를 redis의 ttl로도 해당 maxAge의 값이 사용된다. (express session의 인터페이스는 마치 세션 데이터를 쿠키에 있는 것처럼 사용할 수 있게 한다.)
그렇다면 redis는 어떻게 TTL기능이 동작하는 것인가? 처음에는 내가 직접 세션의 만료를 구현해야 될지도 모른다고 생각해서 몇가지 방식을 미리 생각해 봤었다.
- Cron으로 모든 데이터의 만료 시간 식별 후 삭제
- 만료 tree를 만들어서 데이터가 생성될 때 만료시간을 tree에 삽입하고 주기적으로 혹은 어떤 요청이 들어왔을 때 만료된 tree의 값들을 한번에 제거하는 방식(순서대로 저장되있기 때문에 모든 데이터를 비교하지 않는다)
- mongoDB에서 delete시에 일어나는 일처럼 데이터가 만료되었다는 것으로 덮어씌우는 방법
실제로 redis가 ttl을 처리하는 방법은 다음과 같았다.
https://www.pankajtanwar.in/blog/how-redis-expires-keys-a-deep-dive-into-how-ttl-works-internally-in-redis
- 수동적 만료
만료된 key가 들어올때 만료되었는지 확인하고 삭제하는 방식이다. key가 만료되었는지 확인하려면 요청이 들어와야되고 요청이 없다면 계속 남아있게 된다. - 능동적 만료
이 방식은 마치 위의 cron과 비슷하다. 나는 cron이 가장 비효율적인 방식이라고 생각했는데 redis는 이를 확률적으로 접근해서 처리한다.
주기적으로 랜덤한 n개의 키가 만료되었는지 확인한다. 만료된 키를 삭제하면서 25%이상 키가 만료된 경우 이 작업을 다시 반복한다. 즉 삭제해야 할 데이터가 많은 경우 꾸준히 삭제 알고리즘이 돌아가는 방식을 통해 확률적으로 25%의 만료된 데이터만이 남아있도록 유지한다.
TIL과 알고리즘