토큰 관련 협의사항

[caboooom]

댓글로 이야기 나왔던 것들 다 정리해봅시다

[DongMirror]

이슈

• 토큰 관리를 어떻게 할 것인가

방안

• ip인증 방식 처음 로그인할시에 해당 기기의 ip를 받아와 요청 올때마다 비교 단점: 외부 아이피 , 와이파이와 같은 아이피로 들어올경우 중복 아이피 해결 : 외부 사설 아이피를 차단하고 특정 아이디에게만 권한 부여

• 리프레시 토큰 리프레시 기간 안 동안 토큰 재발급 가능 하지만, 장시간 켜놓는 이 프로젝트 특성상 리프레시 토큰이 필요치 않음

• 토큰 로테이션 관리자페이지에서 띄어 놓기만하고 아무 요청도 안한다고 가정하면 다른 사용자가 탈취해 사용해도 모를수가 있음

결론

토큰 기간을 1시간으로 하고 메인 관리자 페이지는 웹 소켓으로 연결하여 실시간 데이터 확인 1시간이 지나 요청을하면 재 로그인

[caboooom]

리프레시토큰은 안 쓰는 게 맞다.

• 이유: 우리 서비스 특성상, 자동로그인이 된다거나 로그인 유지 기간 길어지면 보안상 위험하기 때문

기기 인증 방식

• 기기 MAC주소로 인증하는 방식
• 만약 관리자가 퇴근했는데 문제가 생겨서 대시보드 확인해야 하는 경우는?
• 그리고 찾아보니 자바+스프링에서 MAC주소를 가져올 수 있는 방법이 없다

토큰 분리

• 사용자 인증만 해주는 토큰 & 리소스 접근만 허용해주는 토큰 따로 분리
• 리소스 가져올 때마다 사용자 인증 정보 왔다갔다 해야 하는 문제는 해결 가능

30분 간격으로 헬스 체크

• 관리자가 로그인 하고 대시보드 띄워놓고 가만히 있는 동안 토큰 탈취당한 경우 가정
• 해커가 이 토큰으로 새로운 토큰을 발급받아 정보를 탈취할 수도 있다
• 관리자가 가만히 있어도, 30분마다 액세스 토큰을 가지고 서버에 요청보내도록 한다면?
• 같은 아이디로 2명 이상의 사용자가 요청을 보낸다면 대조해서 30분 안에 잡아낼 수 있다
• 근데 관리자가 토큰 탈취당한 후 30분이 되기 전에 로그아웃 해버린다면???

결론

• 액세스 토큰 로테이션: 1시간마다 엑세스 토큰 갱신

• 대시보드를 띄우면 웹소켓을 열어서 리소스 보내줌

• 관리자 페이지는 1시간마다 로그인하도록 한다

• 이유:

  • 토큰 탈취당하더라도 1시간 안에는 잡을 수 있음
  • 보안을 위해서 관리자가 1시간마다 로그인 풀리는 불편함은 감수해도 된다고 생각

[jeongyongs]

인증 문제

문제 상황

현재 액세스 토큰만 가지고 인증을 수행하고 있습니다. 액세스 토큰의 만료 시간을 1시간으로 가져가기 때문에, 사용자는 최초 로그인으로부터 한 시간이 지나면 재로그인을 해야합니다. 이로인해 사용자 경험이 저하될 수 있다는 문제가 제기되었습니다.

솔루션

1. 액세스 토큰 만료시간 연장

사용자 경험을 향상 시키기 위해 액세스 토큰의 만료 시간을 길게 가져갈 수 있습니다. 액세스 토큰은 서버에서 관리하지 않기 때문에, 서버는 단지 유효성 검증만 수행하고 인가를 해주게됩니다. 따라서 이 방법은 토큰이 탈취되는 상황에서 보안성을 심히 저하시키는 부작용이 있습니다.

2. 리프레시 토큰 도입

1번 솔루션의 문제를 완화하고자 액세스 토큰의 만료기간을 짧게 가져가고, 대신 리프레시 토큰을 도입하여 짧은 액세스 토큰의 단점을 보완합니다. 리프레시 토큰은 서버에 저장되므로 로그아웃과 같이 서버에서 관리가 가능합니다. 하지만, 리프레시 토큰의 관리 방법에 대해 신경을 써야합니다. 또한 탈취 여부를 파악할 수 있도록 리프레시 토큰 로테이션 기법을 사용할 수 있습니다.

3. 액세스 토큰 로테이션

프로젝트의 특성상 관계자 외에 불특정 다수가 서비스를 사용하지 않습니다. 또한 실시간 데이터를 다루기 때문에 보안이 중요합니다. 따라서 로그인 유지 기능은 필요 없을 것으로 판단했습니다. 기존 액세스 토큰을 서버에 저장하고 관리합니다. 쿠키의 만료 시간을 세션으로 한정하고, 브라우저가 종료되면 재로그인을 합니다. 로그인을 한 경우에 한 시간 이내로 재 요청이 없으면 토큰이 만료됩니다. 토큰이 만료되기 전에 재 요청이 들어오면 토큰을 재발급하여 만료시간을 한 시간으로 초기화 합니다. 또한 탈취 상황을 고려하여 각 토큰은 단 한 번만 갱신할 수 있습니다. 만약 두 번 이상 갱신 요청이 들어올 경우 토큰이 탈취된 것으로 가정하고 모든 토큰을 무효화합니다. 하지만, 이 방법의 경우 사용자가 재요청을 하지 않는다면 탈취당한 토큰은 계속 사용되게 됩니다.

4. 기존 방식

상황실에서 모니터에 대시보드를 띄워두기만 할 경우 최초 웹소켓 요청 시에만 토큰이 사용되므로 연결 후에는 토큰이 만료되더라도 데이터를 받을 수 있습니다. 또한 토큰이 탈취되더라도 토큰의 유효 기간이 한 시간으로 제한됩니다. 관리자(사용자)의 경우 연속으로 한 시간 이상 작업이 유지되야할 경우가 없고, 보안 향상을 위해 한 시간 마다 로그인하는 것은 관리자가 충분히 수용할 수 있다 판단됩니다.

최종 결론

프로젝트의 목적과 보안 사항을 고려했을 때 현 상태를 유지하는 것으로 결정했습니다.

[codethestudent]

토큰 관련 협의 사항

1. JWT 액세스 토큰의 탈취 문제

   로그인 시 발급되는 JWT 액세스 토큰이 탈취될 경우의 보안 위험을 언급하며, 이를 방지하기 위해 액세스 토큰의 유효 기간을 짧게 설정하여 사용자가 자주 로그인하도록 하는 방안을 제안하였습니다.

2. 사용자 경험과 보안 사이의 균형

   액세스 토큰의 짧은 유효 기간으로 인해 발생할 수 있는 사용자 경험의 저하 문제를 해결하기 위해, 리프레시 토큰을 도입하여 액세스 토큰이 만료될 때마다 리프레시 토큰을 사용해 자동으로 토큰을 갱신하도록 하여 사용자 만족도를 향상시키는 방안을 논의하였습니다.

3. 리프레시 토큰의 보안 강화

   액세스 토큰과 리프레시 토큰이 동시에 탈취되는 경우의 위험성을 인식하고, 토큰 로테이션 기법을 적용하여 악의적 사용자가 리프레시 토큰을 이용해 액세스 토큰을 재발급 받으려 할 때 Redis에 저장된 변수 값을 검증하여 비정상적인 행위를 감지하고, 필요한 경우 모든 리프레시 토큰을 무효화하는 조치를 취하기로 결정하였습니다.

4. 보안 우선 접근

   프로젝트의 주요 요구사항이 상시 모니터링이나 백엔드 서버에의 빈번한 요청을 처리하는 웹 서비스가 아닌 점을 고려하여, 악의적인 사용자가 토큰을 오래 동안 보유하지 못하도록 하기 위해 액세스 토큰의 만료 기간을 1시간으로 설정하고, 사용자가 1시간마다 로그인하도록 하는 방식이 보안 강화에 더욱 적합하다고 결론지었습니다. 이는 사용자 경험과 보안 사이의 상충관계에서 보안을 우선시하는 접근입니다.