하루에 한 번 만료되는 httponly의 직선 jwt에서 새로 고침/무기명 토큰 방식으로 내 인증 전략을 변경하려고했습니다. 그러나 새로 고침 토큰은 새로운 토큰을 만들 수 있으므로 큰 위험을 초래하지 않습니까? 왜 사람들은 이것을 추천합니까? 내가 뭔가 빠졌습니까?JWT 새로 고침 토큰 여부
답변
토큰을 가로채는 사람은 누구나 정기적으로 새로 고칠 수 있고 기본적으로 만료되지 않는 토큰처럼 기본적으로 영구적 인 액세스 권한을 가질 수 있기 때문에 신선함을 확보해야하는 유일한 방법은 쓸모가 없습니다.
토큰 새로 고침을 수행 할 때 사용자/패스가 필요하지 않고 이전 토큰이 무효화되면 토큰을 가로채는 사람이 실제 토큰을 무효화하는 동시에 새로운 토큰을 만들 수 있으므로 위험합니다. 따라서 누군가가 귀하의 계좌에 액세스 할 수있을뿐만 아니라 부상 당했다는 모욕을주기 위해 스스로 액세스 할 수 없게됩니다.
새 토큰을받은 후 이전 토큰이 여전히 유효하고 사용자/패스가 필요하지 않은 경우 토큰을 가로채는 사람이 수천 개의 새 토큰을 만들 수 있으며 모든 토큰이 유효하며 모든 토큰이 다음으로 새로 고침 될 수 있습니다. 더 많은 토큰을 얻으십시오. 데이터베이스에 저장되는 경우 서비스 거부 공격의 벡터가 될 수 있습니다. 그것들이 데이터베이스에 저장되어 있지 않다면 그 중 어떤 것이 아직 유통되고 있는지 알 방법이 없으며 그것들을 무효로 할 방법이 없습니다.
새 토큰을 얻기 위해 사용자/패스 또는 다른 자격 증명을 사용해야하는 경우 누출 된 토큰은 토큰 만 사용하여 새로 고칠 수 없으므로 얼마 동안 만 유효하지만 실제 사용자 사용자를 보내야하거나 더 자주 전달해야하므로 자격 증명을 가로채는 데 더 많은 가능성이 있습니다.
위의 모든 접근법은 실제 서비스에서 실제 상황에서 이루어졌습니다.
토큰을 새로 고침하면 새로 만들어지기 때문에 시간이 지나면 이전 토큰이 만료되므로 다른 사람이 토큰을 보유한다고 가정하면 서버가 자동으로 만료되기 때문에 이전 버전은 거의 없거나 그를 사용하지 않아.
내 모든 지점은 무기 토큰 보안에 관한 것이 아니라 약 리프레쉬 토큰의 시큐리티 내가 이것을 해커, 게임 끝까지 붙잡 으면 마음대로 토큰을 산거야. 나는 이것에 대한 해답이 토큰 블랙리스트 화라는 것을 알고 있지만 검정색 리프레쉬 토큰을 식별하는 로직을 추가했다. – user2331566
토큰을 가지고 있을지도 모르는 위험한 게임 인 것처럼 들리므로 해커가 토큰을 받더라도 그는 동일한 IP를 가져야합니다. –
예, 해킹 당할 수있는 csrf 방어에 대한 이야기입니다. 또한 xss 공격은 실제 사용자가 자신의 계정에서 해킹을 요청할 때 IP 방어를 우회합니다. 토큰에 도달 할 수 없다고 가정하고 해커가 사용자가 코드를 실행할 수 없다고 가정 해 봅시다. 일단 토큰 팩토리를 생성하면 무서운 취약점이 도입되었습니다. 이 큰 서비스는 어떻게 이것이 훌륭한 시스템이라고 말하는가? – user2331566
액세스 및 OpenID on Oauth2에 설명 된대로 다른 목적이 토큰을 새로 고침 :
- 액세스 토큰 : 보호 된 자원에 임시로 액세스, 매우 짧은 수명, 심지어 하나의 사용 권한을 부여
- 새로 고침 토큰 : 오래 살았던 새로운 토큰을 얻을 수 있도록 보장해야합니다. OAuth2를 인증 흐름
는 성공적인 사용자 인증 후에, 서버는 토큰 엔드 포인트로부터 액세스 & 갱신 토큰을 얻는 제 2 단계에서 사용할 수있는 인증 코드를 제공한다. 리프레시 토큰은 서버 측과 같이 안전하게 저장된다. 클라이언트 에이전트가 액세스 토큰을 사용하여 인증합니다.
액세스 토큰은 exp
시간까지만 유효합니다. 수명이 짧기 때문에 잠재적 인 도난으로 인한 피해가 제한적입니다. 액세스 토큰이 만료 될 때 보안이 손상되지 않은 새로 고침 토큰은 토큰 끝점에서 새로운 단명 액세스 토큰을 얻는 데 사용됩니다.
새로 고침 토큰은 많은 토큰을 생성 할 수 있으므로 큰 보안 문제는 아니다. 컴퓨터 그룹이 모두 함께 로그인 할 수 있습니다. 실제로 해당 사용자 계정에 대한 액세스 권한을 누구 에게든 부여 할 수 있습니다. – user2331566
사양 (위 링크)의 12.1 절을 참조하십시오. _token endpoint_는 새 토큰을 발행하기 전에 클라이언트를 인증해야합니다 (예 : 디지털 서명의 비밀 키로). 공격자가 새로 고침 토큰을 스톨하더라도 토큰 끝점의 인증 자격 증명을 소유하지 않으므로 사용할 수 없습니다. 새로 고침 토큰은 선택 사항이지만 예를 들어 Google과 같은 OpenID Connect 구현자가 사용합니다. 구현은 간단하지 않으며, 토큰이 백엔드없이 사용자 (예 : 브라우저 또는 장치)에 직접 배포되는 경우 새로 고침 토큰이 너무 유용하지는 않습니다 – pedrofb
이것은 정확하게 내 관심사이지만 auth0은 보안이 향상된다고 주장합니다. 결론은 다음과 같습니다. 결론 (결론 참조) : https://auth0.com/blog/refresh-tokens-what-are-the-and-when- 사용하기 쉽다 /. 무엇을 나 혼란스럽게 했습니까? stormpath는 또한 https://stormpath.com/blog/build-secure-user-interfaces-using-jwts에서 맹세했습니다. 내가 미쳤거나 토큰 관리 – user2331566
을 부팅 할 때 큰 위험이 될 수 있습니다. auth0은 전체 보안 정책을 손상시키는 localStorage에 저장해야한다고 말합니다. 그러나, 나는 stormpaths 정책을 존중한다. 그래서 정말로 나를 비꼬아 넣는다. – user2331566