Gli URL privati ​​non indovinabili equivalgono all'autenticazione basata su password?

Voglio esporre una risorsa sul web. Voglio proteggere questa risorsa: assicurarsi che sia accessibile solo a determinate persone.

Potrei impostare una sorta di autenticazione basata su password . Ad esempio, ho potuto consentire l'accesso alla risorsa solo tramite un server Web che controlla le richieste in arrivo per le credenziali corrette (forse rispetto ad alcuni database di backup degli utenti) prima di pubblicare il file.

In alternativa, potrei semplicemente usare un URL privato . Cioè, potrei semplicemente ospitare la risorsa in un percorso impossibile da indovinare, ad esempio https://example.com/23idcojj20ijf..., che limita l'accesso a coloro che conoscono la stringa esatta.

Dal punto di vista di un malfattore che vuole accedere a questa risorsa, questi approcci sono equivalenti? In caso contrario, cosa li rende diversi? E per quanto riguarda la manutenibilità, ci sono pro e contro di entrambi gli approcci di cui dovrei essere a conoscenza prima di implementare l'uno o l'altro?

Un URL privato è in qualche modo più debole dell'autenticazione con credenziali, anche se la dimensione in bit dell'URL è uguale a quella delle credenziali. Il motivo è che l'URL potrebbe "falla" più facilmente. Viene memorizzato nella cache del browser, registrato sul server e così via. Se si dispone di collegamenti in uscita, l'URL privato potrebbe essere visualizzato nell'intestazione del referrer su altri siti. (Può essere visto anche da persone che guardano alle tue spalle.)

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

Per questo motivo, gli URL privati ​​vengono generalmente utilizzati solo per operazioni one-shot come il ripristino delle password e in genere sono attivi solo per un periodo di tempo limitato.

C'è un thread correlato su 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 dopo che le dichiarazioni fiscali sono finite 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 sul fatto che l'invio del collegamento tramite un'entità attendibile sia un tentativo di autenticazione a due fattori. Per essere chiari, stiamo parlando di una risorsa accessibile al pubblico, sebbene sia sufficientemente difficile da indovinare.

Quando si utilizza un URL privato, si dovrebbe sempre presumere che possa essere compromesso - è necessario progettare tale URL in modo tale che, anche se compromesso, la risorsa non perda le informazioni all'attaccante.

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 al pubblico. Penso che il termine URL "privato" sia un termine improprio, piuttosto sono URL "oscuri".

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

Alcuni dei luoghi che ho visto comunemente usati URL "privati" sono:

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

La cosa comune qui è che gli URL casuali sono in genere buoni solo per le operazioni one-shot. Inoltre, l'autenticazione tradizionale e gli URL casuali non si escludono a vicenda , anzi, possono essere utilizzati insieme per fornire ulteriore sicurezza durante la consegna 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 e-mail, SMS, ecc.

Un URL privato / generato in modo casuale 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 rinviare l'autenticazione dell'utente a qualche altra entità di cui si fida per autenticare in modo sicuro l'utente. (Inviando il collegamento via e-mail o SMS, ecc.)
4. Dovrebbe essere impossibile per un computer moderno forzare bruscamente l'URL nel periodo precedente la scadenza - o limitando la velocità dell'API che espone la risorsa o creando un endpoint url con entropia sufficiente in modo che non possa essere indovinato.
5. Non dovrebbe perdere informazioni sull'utente. IE: se la pagina deve reimpostare una password: la pagina non deve visualizzare le informazioni sull'account dei richiedenti. Se Alice richiede un collegamento per reimpostare la password e Bob indovina in qualche modo l'URL, Bob non dovrebbe avere modo di sapere di chi sta reimpostando la password.
6. Se perde informazioni sull'utente, dovrebbe essere utilizzato in aggiunta all'autenticazione tradizionale, ad esempio una pagina può considerare un utente autenticato se ha un cookie impostato o se il suo session_id è ancora valido.

Risorse diverse richiedono diversi livelli di sicurezza. Se vuoi condividere una ricetta segreta con alcuni amici, ad esempio, sarebbe accettabile usare un URL casuale / privato per condividerlo con loro. Tuttavia, se la risorsa potesse essere utilizzata per rubare l'identità di qualcuno o compromettere i propri account con altri fornitori di servizi, è probabile che ti interessi molto di più a limitare l'accesso a tale risorsa.

Praticamente tutti gli schemi di autenticazione si riducono a dimostrare che si conosce un segreto. Ti autentichi in qualche servizio dimostrando di conoscere una password segreta o un URL segreto o, ...

Alcuni protocolli più avanzati (ad es. OAUTH, Kerberos, ...) ti consentono di dimostrare di conoscere il segreto senza trasmetterlo effettivamente . Questo è importante perché ci sono altri modi per ottenere un segreto "indiscutibile" oltre a indovinarlo.

Potrei essere seduto nello stesso Internet café di te, intercettando la tua connessione WiFi quando digiti il ​​tuo URL "non indelebile". A quel punto, se non stavi usando SSL, o se potessi sfruttare l'ultimo nuovo bug nella tua implementazione SSL, allora conoscerei anche il tuo segreto.

Molte buone risposte già in questa discussione, ma per rispondere direttamente alla domanda:

Dal punto di vista di un malfattore che vuole accedere a questa risorsa, questi approcci sono equivalenti? In caso contrario, cosa li rende diversi?

Vorrei stabilire una definizione. "Autenticazione" è la fornitura di credenziali per dimostrare una rivendicazione di identità. Il controllo degli accessi si basa generalmente 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 in cui potrebbe fuoriuscire.

D'altra parte, una password è legata a un account utente univoco. Hai la possibilità di ripristinarlo o di consentirne l'utilizzo solo dalla posizione di residenza dell'utente, dall'indirizzo IP noto o da un numero qualsiasi di altri controlli.

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

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

Vai con il nome utente / password se puoi. Gli URL si perdono nel tempo in molti modi inaspettati.

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

Ad esempio, il tuo browser non mostrerà una password sullo schermo, memorizzerà solo le password con la tua autorizzazione e offrirà i mezzi per proteggere quella password (come la memoria crittografata sbloccata da una password principale). Al contrario, mostrerà sempre gli URL sullo schermo, potrebbe eventualmente perderli attraverso l'intestazione del referrer e salvarli 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'uso degli URL per l'autenticazione significa anche che la condivisione degli URL condivide l'autenticazione, il che rende difficile revocare (o registrare) individualmente l'accesso.

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

Un altro elemento non notato da nessuna parte è la limitazione di "ipotesi". Per la maggior parte dei sistemi di autenticazione con 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 potresti fare qualcosa di simile con "ipotesi" contro il tuo schema URL, sarebbe un po 'più difficile da implementare. Se esiste un modello riconoscibile per la generazione dell'URL, potrebbe essere difficile impedire a qualcuno di configurarsi per farsi strada nello spazio URL "casuale".

C'è un altro aspetto che non ho ancora visto menzionato: accorciatori di URL.

In una recente pubblicazione (aprile 2016), è stato affermato che i servizi di abbreviazione di URL annullano completamente la maggiore sicurezza fornita da URL "non indovinabili" 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 abbreviato può essere indovinato in modo più semplice del previsto.

Per illustrare, supponiamo che l'URL casuale sia lungo 128 bit (ovvero un guid). Inoltre, supponiamo che il tuo generatore di numeri casuali sia davvero forte e che generi quei bit in modo uniforme. Indovinare un numero a 128 bit è molto difficile e può richiedere molto tempo: l'URL è effettivamente protetto con chiave a 128 bit.

Quindi, supponiamo che qualcuno abbia condiviso questo URL sull'accorciatore di URL di Google. Oggi quel servizio emette un ID lungo 10 caratteri, composto da lettere e numeri. (26 + 10) ^ 10 ~ = 3,6 * 10 ^ 15 <2 ^ 52 - quindi abbiamo dimezzato l'intensità della chiave da 128 bit a 52 bit.

Aggiungete a ciò 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 pre-allocati).

L'articolo originale: http://arxiv.org/pdf/1604.02734v1.pdf
Un post sul blog che sintetizza l'articolo (dell'autore): https://freedom-to-tinker.com/blog/vitaly/gone-in- sei personaggi-corto-urls-considerato nocivo-per-nube-services /