Gli URL privati e non guidabili equivalgono all'autenticazione basata su password?

Un URL privato è un po 'più debole dell'autenticazione con le credenziali, anche se la dimensione del bit dell'URL è la stessa di quella delle credenziali. Il motivo è che l'URL potrebbe più facilmente "perdita". È memorizzato nella cache del browser, registrato sul server e così via. Se disponi di link in uscita, l'URL privato può essere visualizzato nell'intestazione del referrer su altri siti. (Può anche essere visto da persone che guardano oltre la tua spalla.)

Se perde (per sbaglio o per negligenza dell'utente), potrebbe finire per essere pubblico e persino indicizzato da Google, che consentirebbe a un utente malintenzionato di cercare facilmente tutti gli URL trapelati al tuo sito!

Per questo motivo, gli URL privati vengono in genere utilizzati solo per le operazioni one-shot come le reimpostazioni della password e in genere sono attivi solo per un periodo di tempo limitato.

Esiste un thread correlato in Sicurezza delle informazioni: Gli URL casuali sono un modo sicuro per proteggere le foto del profilo ? - una risposta condivide questa storia: Dropbox disabilita i vecchi link condivisi al termine della dichiarazione dei redditi su Google . Quindi non è solo un rischio teorico.

Nota:

Molte persone sembrano confondere un URL "privato" con l'autenticazione. Inoltre, sembra esserci una certa confusione che l'invio del link tramite un'entità fidata è un tentativo di autenticazione a due fattori. Per essere chiari, stiamo parlando di una risorsa accessibile al pubblico, anche se è sufficientemente difficile da indovinare.

Quando si utilizza un URL privato, si dovrebbe sempre presumere che possa essere compromesso: è necessario progettare un URL di questo tipo in modo che, anche nel caso in cui venga compromesso, la risorsa non perderà informazioni all'autore dell'attacco.

Gli URL privati / difficili da indovinare non equivalgono all'autenticazione basata su password. Per natura, gli URL privati non sono affatto privati: sono risorse accessibili pubblicamente. Penso che il termine URL "privato" sia un termine improprio, piuttosto sono URL "oscuri".

Ci sono alcuni casi in cui l'uso di un URL "privato" è accettabile, ma sono intrinsecamente meno sicuri rispetto ai metodi di autenticazione tradizionali come l'autenticazione della password o l'autenticazione basata su chiave.

Alcuni dei luoghi in cui ho comunemente visto gli URL "privati" sono:

1. Email di reimpostazione della password
2. Email di generazione certificato
3. Email di conferma dell'account / email
4. Consegna dei contenuti acquistati (e-book, ecc.)
5. Altre cose diverse come il check-in di volo, la carta d'imbarco della stampa, l'uso di URL privati oltre all'autenticazione tradizionale

La comunanza qui è che gli URL casuali sono tipicamente validi solo per le operazioni one-shot. Inoltre, l'autenticazione tradizionale e gli URL casuali non si escludono a vicenda , anzi, possono essere utilizzati in combinazione tra loro per fornire ulteriore sicurezza durante il recapito di una risorsa.

Come ha sottolineato Robert Harvey, l'unico modo per utilizzare in modo sicuro un URL casuale / privato è generare la pagina in modo dinamico e inviare l'URL all'utente in modo tale che l'utente possa essere considerato semi-autenticato. Questo potrebbe essere email, SMS, ecc.

Un URL generato in modo casuale / privato ha in genere alcune proprietà:

1. Dovrebbe scadere dopo un ragionevole lasso di tempo
2. Dovrebbe essere un URL monouso: IE dovrebbe scadere dopo il primo accesso.
3. Dovrebbe posticipare l'autenticazione dell'utente ad un'altra entità che si fida per autenticare in sicurezza l'utente. (Inviando il link via email o SMS, ecc.)
4. Dovrebbe essere impossibile per un computer moderno forzare bruscamente l'URL nel periodo di tempo che precede la scadenza - sia per la velocità che limita l'API che espone la risorsa sia per la creazione di un endpoint dell'URL con sufficiente entropia tale da non poter essere indovinato. / li>
5. Non dovrebbe perdere informazioni sull'utente. IE: se la pagina deve reimpostare una password: la pagina non deve visualizzare le informazioni dell'account del richiedente. Se Alice richiede un link per reimpostare la password e Bob in qualche modo indovina l'URL, Bob non dovrebbe sapere in alcun modo di quale password si sta reimpostando.
6. Se perde informazioni sull'utente, dovrebbe essere usato in aggiunta all'autenticazione tradizionale, ad esempio una pagina potrebbe considerare un utente autenticato se ha un set di cookie o se il suo session_id è ancora valido.

Diverse risorse richiedono diversi livelli di sicurezza. Ad esempio, se desideri condividere una ricetta segreta con alcuni amici, sarebbe accettabile utilizzare un URL casuale / privato per condividerlo con loro. Tuttavia, se la risorsa potrebbe essere utilizzata per rubare l'identità di qualcuno o compromettere i propri account con altri fornitori di servizi, probabilmente ci si preoccuperà molto di più di limitare l'accesso a tale risorsa.

Quasi tutti gli schemi di autenticazione si riducono a dimostrare che conosci un segreto. Ti autentichi ad alcuni servizi dimostrando di conoscere una password segreta o un URL segreto o ...

Alcuni protocolli più avanzati (ad esempio, OAUTH, Kerberos, ...) ti consentono di dimostrare che conosci il segreto senza in realtà trasmettere il segreto. Questo è importante perché ci sono più modi per ottenere un segreto "non percettibile" oltre a indovinarlo.

Potrei stare seduto nello stesso Internet cafè di te stesso, ad ascoltare la tua connessione WiFi quando digiti il tuo URL "non accessibile". A quel punto, se non si stesse usando SSL, o se potessi sfruttare il nuovo bug più recente nella tua implementazione SSL, allora saprei anche il tuo segreto.

Un sacco di buone risposte già in questa discussione, ma per indirizzare direttamente la domanda:

From the perspective of an evildoer who wants to access this resource, are these approaches equivalent? If not, what makes them different?

Fammi stabilire una definizione. "Autenticazione" è la fornitura di credenziali per dimostrare una rivendicazione di identità. Il controllo dell'accesso si basa in genere sull'identificazione dell'utente.

Il tuo URL segreto non è associato a un utente specifico. Come altri hanno sottolineato, potrebbe finire nel file di registro di un proxy, o in una richiesta di ricerca che viene indicizzata da google, o in molti altri modi che potrebbe trapelare.

D'altra parte, una password è legata a un account utente univoco. Hai la possibilità di reimpostarlo o di permetterne l'utilizzo solo dalla posizione di origine dell'utente, dall'indirizzo IP conosciuto o da qualsiasi altro numero di controlli.

Un nome utente / password ti dà un controllo molto più granulare dell'accesso.

Il controllo accessi consente a un accesso di identità (soggetto) a una risorsa (oggetto). Nel tuo esempio di URL l'identità è "chiunque abbia ottenuto l'URL, con qualsiasi mezzo".

Vai con il nome utente / password se puoi. Gli URL si perdono in tutti i modi imprevisti nel tempo.

Un URL segreto è sicuro quanto una password segreta. Tuttavia, le password sono più facili da mantenere segrete rispetto agli URL, perché tutti e i loro programmi sanno che le password devono rimanere segrete.

Ad esempio, il browser non mostra una password sullo schermo, memorizza solo le password con la tua autorizzazione e offre mezzi per proteggere tale archivio di password (come la memoria crittografata sbloccata da una password principale). Al contrario, mostrerà sempre gli URL sullo schermo, potrebbe eventualmente trapelarli attraverso l'intestazione del referrer e archiviarli automaticamente nella cronologia di navigazione senza ulteriore protezione.

Allo stesso modo, i proxy HTTP di solito non registrano le password, mentre gli URL vengono comunemente registrati.

L'utilizzo di URL per l'autenticazione significa anche che gli URL di condivisione condividono l'autenticazione, il che rende difficile l'accesso (o la registrazione) individuale alla revoca.

E, naturalmente, gli URL segreti ereditano tutti i punti deboli delle password segrete. In particolare, l'utilizzo di una password per l'autenticazione rivelerà la password al server e chiunque sia in grado di leggere la tua comunicazione.

Un altro elemento non notato da nessuna parte è la limitazione delle "ipotesi". Per la maggior parte dei sistemi di autenticazione delle password, si ottiene un numero limitato di tentativi di indovinare una password per un utente prima che ulteriori tentativi di autenticazione siano bloccati o limitati.

Mentre si potrebbe fare qualcosa di simile con le "ipotesi" contro il proprio schema URL, sarebbe un po 'più difficile da implementare. Se esiste un modello riconoscibile per la generazione di URL, potrebbe essere difficile impedire a qualcuno di configurarsi per elaborare il proprio spazio URL "casuale".

C'è un altro aspetto che non ho ancora visto menzionato - abbreviazioni URL.

In una recente pubblicazione (aprile 2016), è stato affermato che i servizi di abbreviazione URL annullano completamente la maggiore sicurezza fornita da URL "non guidabili" generati casualmente. Lo spazio URL del servizio shorterner è considerevolmente più piccolo dell'URL generato casualmente, il che significa che qualsiasi URL "sicuro" condiviso con un servizio shortener può essere indovinato in modo più semplice del previsto.

Per illustrare - supponiamo che il tuo URL casuale sia lungo 128 bit (cioè un guid). Inoltre, supponiamo che il tuo generatore di numeri casuali sia davvero strong e che tu generi quei bit in modo uniforme. Indovinare un numero a 128 bit è molto difficile e può richiedere molto tempo: il tuo URL è effettivamente protetto da chiavi a 128 bit.

Quindi, supponiamo che qualcuno abbia condiviso questo URL nella riduzione URL di Google. Oggi quel servizio emette un ID di 10 caratteri, composto da lettere e numeri. (26 + 10) ^ 10 ~ = 3.6 * 10 ^ 15 < 2 ^ 52 - quindi abbiamo effettivamente dimezzato la forza della chiave da 128 bit a 52 bit.

Aggiungete il fatto che i generatori non usano l'intero spazio a causa di altre considerazioni e potete montare un attacco efficace che combina la forza bruta con i canali laterali (molto probabilmente buffer di URL casuali preassegnati).

L'articolo originale: link
Un post sul blog che riassume l'articolo (dall'autore): link