추측 할 수없는 비공개 URL은 비밀번호 기반 인증과 동일합니까?

웹에서 리소스를 공개하고 싶습니다. 이 리소스를 보호하고 싶습니다. 특정 개인 만 액세스 할 수 있도록합니다.

일종의 암호 기반 인증을 설정할 수 있습니다. 예를 들어, 파일을 제공하기 전에 들어오는 요청에서 올바른 자격 증명 (아마도 일부 사용자 백업 데이터베이스에 대해)을 확인하는 웹 서버를 통해서만 리소스에 액세스 할 수있었습니다.

또는 개인 URL을 사용할 수도 있습니다 . 즉, 추측하기 어려운 경로에서 리소스를 간단히 호스팅 할 수 있습니다. 예를 들어 https://example.com/23idcojj20ijf...정확한 문자열을 아는 사람들에게 액세스를 제한합니다.

이 자원에 접근하고자하는 행악 자의 관점에서이 접근 방식은 동등합니까? 그렇지 않다면 무엇이 다른가? 그리고 유지 관리성에 관한 한, 하나 또는 다른 것을 구현하기 전에 알아야 할 장단점이 있습니까?

URL의 비트 크기가 자격 증명의 비트 크기와 동일하더라도 개인 URL은 자격 증명을 사용한 인증보다 다소 약합니다. 이유는 URL이 더 쉽게 "누설"될 수 있기 때문입니다. 브라우저에 캐시되어 서버에 로그온됩니다. 아웃 바운드 링크가 있으면 개인 URL이 다른 사이트의 리퍼러 헤더에 표시 될 수 있습니다. (어깨를보고있는 사람들도 볼 수 있습니다.)

유출 (사고 또는 사용자의 부주의로 인해) 된 경우 Google에서 공개하고 색인을 생성하여 공격자가 사이트에 유출 된 모든 URL을 쉽게 검색 할 수 있습니다.

이러한 이유로 개인 URL은 일반적으로 암호 재설정과 같은 원샷 작업에만 사용되며 일반적으로 제한된 시간 동안 만 활성화됩니다.

정보 보안에는 관련 스레드가 있습니다. 임의의 URL은 프로필 사진을 보호하는 안전한 방법 입니까? -하나의 답변이이 이야기를 공유합니다 : Dropbox는 세금 환급이 Google에 끝난 후 이전 공유 링크를 비활성화합니다 . 따라서 이것은 단지 이론적 인 위험이 아닙니다.

노트 :

많은 사람들이 "비공개"URL과 인증을 혼동하는 것 같습니다. 또한 신뢰할 수있는 엔터티를 통해 링크를 보내는 것이 이중 인증 시도라는 혼동이있는 것 같습니다. 분명히, 우리는 추측하기는 어렵지만 공개적으로 접근 가능한 자원에 대해 이야기하고 있습니다.

개인 URL을 사용할 때는 항상 URL이 손상 될 수 있다고 가정해야합니다. URL이 손상 되더라도 리소스가 공격자에게 정보를 유출하지 않도록 그러한 URL을 설계해야합니다.

추측하기 어려운 개인 URL은 암호 기반 인증과 동일하지 않습니다. 본질적으로 비공개 URL은 전혀 비공개가 아니며 공개적으로 액세스 가능한 리소스입니다. '비공개'URL이라는 용어는 잘못된 단어라고 생각합니다.

"비공개"URL을 사용하는 것이 허용되는 경우가 있지만 암호 인증 또는 키 기반 인증과 같은 기존 인증 방법보다 기본적으로 안전하지 않습니다.

내가 자주 사용하는 "비공개"URL은 다음과 같습니다.

1. 비밀번호 재설정 이메일
2. 인증서 생성 이메일
3. 계정 / 이메일 확인 이메일
4. 구매 한 콘텐츠 (전자 책 등) 제공
5. 비행기 탑승 수속, 인쇄 탑승권, 기타 전통적인 URL 외에도 개인 URL을 사용하는 기타 기타 사항

여기서 공통점은 임의 URL은 일반적으로 한 번의 작업에만 적합하다는 것입니다. 또한 기존 인증과 임의 URL 은 상호 배타적이지 않으며 실제로는 리소스를 제공 할 때 추가 보안을 제공하기 위해 서로 함께 사용될 수 있습니다.

Robert Harvey가 지적했듯이 임의 / 비공개 URL을 안전하게 사용하는 유일한 방법은 페이지를 동적으로 생성하고 사용자가 반 인증 된 것으로 간주 될 수 있도록 URL을 사용자에게 제출하는 것입니다. 이메일, SMS 등이 될 수 있습니다.

임의로 생성 / 비공개 URL에는 일반적으로 몇 가지 속성이 있습니다.

1. 적당한 시간이 지나면 만료됩니다
2. 일회용 URL이어야합니다. IE 처음 액세스 한 후에 만료됩니다.
3. 사용자의 인증을 신뢰하는 다른 엔티티에 대한 사용자의 인증을 연기해야합니다. (이메일이나 SMS 등을 통해 링크를 보내면)
4. 현대의 컴퓨터는 리소스를 노출시키는 API를 제한하거나 추측 할 수없는 충분한 엔트로피를 가진 URL 엔드 포인트를 생성함으로써 만료 전 타임 프레임에서 URL을 무차별하게하는 것은 불가능합니다.
5. 사용자에 대한 정보를 유출해서는 안됩니다. IE : 페이지가 비밀번호를 재설정하는 경우 : 요청자 계정 정보가 페이지에 표시되지 않아야합니다. Alice가 비밀번호 재설정 링크를 요청하고 Bob이 URL을 추측하는 경우 Bob은 자신이 재설정중인 비밀번호를 알 수있는 방법이 없어야합니다.
6. 사용자에 대한 정보가 유출되는 경우 기존 인증 위에 사용해야합니다. 예를 들어, 쿠키가 설정되어 있거나 session_id가 여전히 유효한 경우 페이지에서 사용자를 인증 된 것으로 간주 할 수 있습니다.

리소스마다 다른 수준의 보안이 필요합니다. 예를 들어, 친구와 비밀 레시피를 공유하려면 무작위 / 비공개 URL을 사용하여 공유 할 수 있습니다. 그러나 리소스를 사용하여 누군가의 신원을 도용하거나 다른 서비스 제공 업체와의 계정을 손상시킬 수 있다면 해당 리소스에 대한 액세스를 제한하는 데 훨씬 더 관심이있을 것입니다.

거의 모든 인증 체계가 비밀을 알고 있음을 증명합니다. 당신은 당신이 비밀 암호 또는 비밀 URL을 알고 있음을 증명함으로써 일부 서비스에 자신을 인증하거나 ...

더 고급 프로토콜 (예 : OAUTH, Kerberos 등)을 사용하면 실제로 비밀을 전송 하지 않고 비밀을 알고 있음을 증명할 수 있습니다 . 추측 할 수없는 "비밀 한"비밀을 얻는 더 많은 방법이 있기 때문에 이것은 중요합니다.

나는 당신과 같은 인터넷 카페에 앉아, 당신이 당신의 "믿을 수없는"URL을 입력 할 때 WiFi 연결을 도청 할 수 있습니다. 그 시점에서 SSL을 사용하지 않았거나 SSL 구현의 최신 버그를 악용 할 수 있다면 비밀도 알고 싶습니다.

이 스레드에는 이미 많은 좋은 답변이 있지만 질문을 직접 해결하기 위해 :

이 자원에 접근하고자하는 행악 자의 관점에서이 접근 방식은 동등합니까? 그렇지 않다면 무엇이 다른가?

정의를 설정하겠습니다. "인증"은 자격 증명을 증명하기 위해 자격 증명을 제공하는 것입니다. 액세스 제어는 일반적으로 사용자 식별을 기반으로합니다.

비밀 URL은 특정 사용자에게 바인딩되지 않습니다. 다른 사람들이 지적했듯이 프록시의 로그 파일이나 Google이 색인을 생성하는 검색 요청 또는 유출 될 수있는 다른 많은 방법으로 끝날 수 있습니다.

반면에 암호는 고유 한 사용자 계정에 연결되어 있습니다. 재설정하거나 사용자의 집 위치, 알려진 IP 주소 또는 기타 여러 컨트롤에서만 사용할 수 있습니다.

사용자 이름 / 암호를 사용하면 액세스를보다 세밀하게 제어 할 수 있습니다.

액세스 제어는 자원 (객체)에 대한 신원 (주체) 액세스를 허용합니다. 귀하의 URL 예에서 ID는 "어떤 수단을 통해 든 URL을 얻은 사람"입니다.

가능하면 사용자 이름 / 암호를 사용하십시오. URL은 시간이 지남에 따라 모든 종류의 예기치 않은 방식으로 유출됩니다.

비밀 URL은 비밀 암호와 마찬가지로 안전합니다. 그러나 암호는 URL보다 비밀을 유지하는 것이 더 쉽습니다. 모든 사람과 해당 프로그램은 암호를 비밀로 유지해야한다는 것을 알고 있기 때문입니다.

예를 들어, 브라우저는 화면에 비밀번호를 표시하지 않고 사용자의 권한으로 비밀번호 만 저장하며 해당 비밀번호 스토리지 (예 : 마스터 비밀번호로 잠금 해제 된 암호화 된 스토리지)를 보호하는 수단을 제공합니다. 반대로 항상 화면에 URL이 표시되고 리퍼러 헤더를 통해 URL이 유출 될 수 있으며 추가 보호없이 인터넷 사용 기록에 자동으로 저장 될 수 있습니다.

마찬가지로, HTTP 프록시는 일반적으로 비밀번호를 기록하지 않지만 URL은 일반적으로 기록됩니다.

인증에 URL을 사용하면 URL을 공유 할 때 인증이 공유되므로 액세스를 개별적으로 취소 (또는 기록)하기가 어렵습니다.

물론 비밀 URL은 비밀 암호의 모든 약점을 상속합니다. 특히, 인증에 비밀번호를 사용하면 해당 비밀번호가 서버 및 통신을 읽을 수있는 모든 사람에게 공개됩니다.

어디에도 언급되지 않은 또 다른 항목은 '추측'의 조절입니다. 대부분의 비밀번호 인증 시스템의 경우 추가 인증 시도가 잠기거나 제한되기 전에 사용자의 비밀번호를 추측 할 수있는 횟수가 제한됩니다.

URL 체계에 대해 '추측'과 비슷한 것을 할 수는 있지만 구현하기가 다소 어렵습니다. URL 생성에 인식 가능한 패턴이있는 경우 '임의'URL 공간을 통해 작업하도록 누군가를 설정하는 것을 중지하기 어려울 수 있습니다.

아직 언급하지 않은 또 다른 측면이 있습니다-URL 단축기.

최근 간행물 (2016 년 4 월)에서 URL 단축 서비스는 무작위로 생성 된 "추측 할 수없는"URL이 제공하는 보안 강화를 완전히 무효화한다고 주장했습니다. 단축 서비스의 URL 공간은 임의로 생성 된 URL보다 상당히 작습니다. 즉, 단축 서비스와 공유되는 "보안"URL은 예상보다 쉬운 방식으로 추측 할 수 있습니다.

예를 들어, 임의의 URL 길이가 128 비트 (예 : guid)라고 가정 해 봅시다. 또한 난수 생성기가 실제로 강력하고 해당 비트를 균일 한 방식으로 생성한다고 가정합시다. 128 비트 숫자를 추측하는 것은 매우 어렵고 시간이 오래 걸릴 수 있습니다. URL은 효과적으로 128 비트 키로 보호됩니다.

그런 다음 누군가가 Google URL Shortener에서이 URL을 공유했다고 가정하겠습니다. 오늘날이 서비스는 문자와 숫자로 구성된 10 자 길이의 ID를 방출합니다. (26 + 10) ^ 10 ~ = 3.6 * 10 ^ 15 <2 ^ 52-따라서 키 강도를 128 비트에서 52 비트로 효과적으로 절반으로 줄였습니다.

또한 다른 고려 사항으로 인해 생성기가 전체 공간을 사용하지 않으며 무차별 대입 채널 (대부분 사전 할당 된 임의 URL 버퍼)을 결합하는 효과적인 공격을 수행 할 수 있습니다.

원본 기사 : http://arxiv.org/pdf/1604.02734v1.pdf 기사를
요약 한 블로그 게시물 (저자) : https://freedom-to-tinker.com/blog/vitaly/gone-in- 6 자 길이의 짧은 URL, 유해한 클라우드 서비스 /