[Chore] 현재 인증 토큰 유효 시간이 적절한지 고려해보기

[chaeyeon0130]

No description provided.

[chaeyeon0130]

@HI-JIN2
현재 저희 서비스는 각 토큰의 만료 기간이

access token : 24시간
refresh token(access token을 재발급 받는데 필요한 token) : 72시간

으로 설정되어 있는데요.

일반적으로 access token은 30분 이내, refresh token은 2주 정도로 설정한다고 합니다. 지금 저희 액세스 토큰 유효 기간이 긴 느낌이 있는데, 보안 위협이 실질적으로 체감되지 않는다면 변경할 필요는 없지 않나 싶어용

[jayn2u]

우리 팀 모바일 담당자들을 전부 할당했습니다. 해당 안건 검토하고, 조치 여부 결정합시다. 이슈를 그냥 열어두는 것은 좋지 않다고 생각하고 있어서..ㅎ

[jayn2u]

Grok 3 의견

안녕! 네가 말한 토큰 만료 기간 설정에 대해 의견을 나눠보자. 현재 너희 서비스에서 access token이 24시간, refresh token이 72시간으로 설정되어 있고, 일반적인 기준(보통 access token 30분 이내, refresh token 2주 정도)과 비교했을 때 확실히 access token의 유효 기간이 길게 느껴질 수 있어. 이걸 보안 관점에서 어떻게 볼지, 그리고 변경할 필요가 있는지를 고민해보자.

보안 관점에서 분석

1. Access Token (24시간)

   • 장점: 유효 기간이 길면 사용자가 자주 로그인하거나 토큰을 갱신할 필요가 줄어들어서 UX(사용자 경험)가 편리해질 수 있어. 특히 모바일 앱처럼 사용자 인터랙션이 빈번한 환경에서는 이점이 크지.
   • 단점: access token은 주로 API 요청에 직접 사용되니까, 만약 이게 유출되면 공격자가 24시간 동안 이를 악용할 수 있어. 일반적으로 30분 정도로 짧게 설정하는 이유는 유출 시 피해를 최소화하기 위해서야. 24시간은 이론적으로 보안 위협 노출 창(window)이 훨씬 길다고 볼 수 있지.

2. Refresh Token (72시간)

   • 장점: 72시간은 사용자 입장에서 토큰 갱신 주기가 너무 짧지 않아서 편리할 수 있고, 서버 부하도 어느 정도 줄일 수 있어.
   • 단점: 일반적인 2주(336시간)에 비하면 꽤 짧아. refresh token은 access token을 재발급받는 데 사용되니까, 더 길게 설정하면 사용자가 세션이 끊길 가능성이 줄어들어 UX가 좋아질 수 있어. 다만, refresh token이 유출되면 보안 위협이 크기 때문에 적절한 보호(예: 안전한 저장소, HTTPS 전송)가 중요해.

3. 보안 위협 체감 여부

   • 네가 말한 대로 "보안 위협이 실질적으로 체감되지 않는다면" 굳이 변경 안 해도 된다고 볼 수도 있어. 하지만 이건 현재 위협이 없다는 걸 증명하는 게 아니라, 아직 드러나지 않았을 가능성을 배제할 수 없다는 뜻이기도 하지. 예를 들어, access token이 24시간 동안 유효하다면, 유출 시 피해 규모(시간적 여유)가 훨씬 커질 수 있어.

권장 사항

• Access Token: 24시간은 모바일 앱 환경에서도 보통 권장되는 것보다 긴 편이야. 보안 강화를 위해서 1시간(60분) 정도로 줄이는 걸 고려해보면 어떨까? 이렇게 하면 UX에 큰 영향을 주지 않으면서도 유출 시 노출 시간을 줄일 수 있어. 만약 1시간도 부담스럽다면, 2~4시간 정도로 타협점을 찾아보는 것도 괜찮아.
• Refresh Token: 72시간은 너무 짧지도, 길지도 않은 중간쯤인데, 일반적인 2주로 늘리는 걸 추천해. refresh token은 보통 클라이언트(모바일 앱)에서 안전하게 저장되고, 서버에서 추가 보안 조치(예: 토큰 무효화 메커니즘)를 마련한다면 길게 설정해도 큰 문제가 안 될 가능성이 높아.
• 추가 보안 조치: 토큰 유효 기간 외에도 보안을 강화할 방법이 있어. 예를 들어:
  • 토큰 무효화: 로그아웃 시나 비정상적인 사용이 감지되면 서버에서 토큰을 즉시 무효화.
  • 짧은 세션 + 사용자 확인: access token이 길게 유지되더라도, 민감한 작업(결제 등)에는 추가 인증(예: 비밀번호 재입력)을 요구.
  • 모니터링: 토큰 사용 패턴을 모니터링해서 이상 징후를 탐지.

결론

솔직히 말해서, access token 24시간은 보안 관점에서 조금 위험해 보일 수 있어. "위협이 체감되지 않는다"는 건 긍정적이지만, 보안은 예방이 중요하니까 조금 더 짧게(1~4시간) 조정하는 걸 추천해. refresh token은 UX와 서버 부하를 고려해서 2주 정도로 늘려도 괜찮을 것 같고. 너희 팀 상황(사용자 피드백, 보안 요구사항, 서버 구조 등)에 따라 우선순위를 정하면 좋을 것 같아. 너는 어떻게 생각해? 팀에서 논의할 때 더 고민할 포인트 있으면 말해줘!

[jayn2u]

Chat GPT o3-mini 의견

토큰 만료 시간을 결정할 때는 보안과 사용자 편의성 사이의 균형을 고려해야 합니다. 현재 access token을 24시간, refresh token을 72시간으로 설정해 두셨다면, 아래와 같은 점들을 검토해볼 필요가 있습니다.

1. 보안 측면
   • Access Token 만료 시간이 길 경우:
   만약 토큰이 탈취되었을 때, 탈취자가 해당 토큰을 장기간 사용할 수 있게 되어 보안 리스크가 증가합니다. 보통 access token을 짧게 설정하는 이유는, 토큰이 노출되었을 때 피해 범위를 최소화하기 위함입니다.
   • Refresh Token 만료 시간 조정:
   반면 refresh token의 경우, 비교적 긴 기간을 허용하더라도 토큰 재발급 과정에 추가적인 보안 검증(예: IP, 디바이스 체크 등)을 두면 보안 리스크를 줄일 수 있습니다.

2. 사용자 편의성 측면
   • 자주 로그인/토큰 갱신이 필요한 경우:
   access token이 짧을 경우 사용자가 잦은 인증 과정을 겪게 되어 사용자 경험이 저해될 수 있습니다.
   • 장기 세션 유지:
   현재 설정처럼 긴 만료 시간을 두면 사용자는 상대적으로 편리하게 서비스를 이용할 수 있지만, 보안 위협 발생 시 피해가 커질 수 있습니다.

3. 실질적인 보안 위협과 리스크 평가
   • 만약 현재 시스템이 강력한 기타 보안 조치(예: HTTPS, IP/디바이스 체크, 토큰 무효화 정책 등)를 갖추고 있고, 토큰 탈취 사고가 실질적으로 보고되지 않는다면,
   현재 설정을 유지하면서 추후 위협이 발생할 가능성을 모니터링하는 것도 한 가지 방법입니다.
   • 그러나 보안 사고 발생 가능성을 완전히 배제할 수는 없으므로, 보안 모니터링 강화와 함께 주기적인 리뷰를 통해 만료 시간을 조정하는 방안도 고려해볼 수 있습니다.

결론

보안 위협이 현재 크게 체감되지 않는다면 기존 설정을 유지하면서 다른 보안 강화 조치를 점검하는 것도 합리적인 선택일 수 있습니다. 다만, 보안 환경은 지속적으로 변화하기 때문에, 정기적인 위험 평가와 함께 토큰 만료 시간을 단축하거나 추가 보안 조치(예: refresh token rotation 등)를 도입하는 것을 검토하는 것이 좋습니다.

즉, 현재 설정이 특별히 문제가 없다고 판단되더라도, 최신 보안 동향과 사례를 지속적으로 반영하여 설정을 재검토하는 체계를 마련하는 것을 추천드립니다.

[jayn2u]

공지

위의 정보들은 언제까지나 참고용으로 읽어주세요!