È sicuro affidarsi agli UUID per la privacy?

8

Sto caricando file su S3, dove il nome file è un UUID. Tutti i file caricati sono di pubblico lettura / scrittura, tuttavia questi file sono considerati privati per gli utenti.

È possibile che qualcuno indovini un UUID o provi a caso un gruppo di combinazioni per accedere ad alcuni di questi file?

C'è un modo migliore per proteggere i file S3?

    
posta Snowman 16.03.2014 - 02:23
fonte

2 risposte

9

Gli UUID generati dopo RFC 4122 sono disponibili in diverse "versioni"; in un UUID del modulo xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx (in esadecimale), quindi:

  • Se 8 ≤ N ≤ b e M = 1 o M = 2, l'UUID identifica la macchina che lo ha generato e il tempo in cui è stato generato.
  • Se 8 ≤ N ≤ b e M = 3 o M = 5 allora l'UUID viene generato deterministicamente usando una funzione di hash crittografica.
  • Se 8 ≤ N ≤ b e M = 4 allora l'UUID è casuale (con 6 bit fissi e 122 bit casuali).

Se l'UUID non soddisfa nessuno di questi vincoli, non è stato generato secondo la RFC 4122. Ma anche se i vincoli sono soddisfatti, ciò non garantisce che il RFC è stato seguito, o che il generatore casuale è stato una buona.

Non so cosa faccia S3 per gli UUID.

Anche se gli UUID sono correttamente casuali, il che renderebbe l'URL non percettibile, proteggere l'accesso a una risorsa con un solo URL è una cattiva idea. Gli URL tendono a perdere in molti modi: condivisi nelle e-mail o nelle chat, nelle cronologie dei browser e negli elenchi di segnalibri, accidentalmente copiati o, peggio, lasciati come link in una pagina che l'autore intendeva mantenere privati ma senza autenticazione e è stato indicizzato da Google.

Se si desidera proteggere l'accesso a una risorsa sul Web, non fare affidamento sull'ubicazione segreta dell'URL. Aggiungi un meccanismo di autenticazione. Anche la semplice autenticazione con password vecchia è un enorme miglioramento su un URL non accessibile: i browser e persino le persone sanno che non dovrebbero condividere le password in giro, mentre gli URL sono normalmente di dominio pubblico.

    
risposta data 16.03.2014 - 17:12
fonte
3

La soluzione corretta al 100%, ovviamente, non sarebbe quella di rendere i file leggibili e scrivibili. È fuori controllo qui, ma non è strettamente necessario.

Il server è configurato in modo simile a come incoming le cartelle sono stati creati sul server FTP per 30-40 anni: è possibile cd in quella directory e creare / scrivere file, e leggere tutti i file che è possibile aprire, ma non è possibile elencare il contenuto della directory (e facoltativamente, è possibile creare e scrivere qualsiasi file, ma non sovrascriverne uno esistente).

Supponendo che i nomi dei file non possano essere indovinati, questo è sicuro nella misura in cui non si può fare molto senza conoscere il nome di un file. Un UUID ha 128 bit, ma è possibile utilizzare qualsiasi altro nome di file casuale della stessa dimensione o maggiore (o un nome casuale a 160 bit, se si pensa che 128 bit non siano sufficienti).
Mentre è in teoria possibile indovinare un numero casuale a 128 bit (e c'è anche la possibilità che due nomi di file si scontreranno per caso), le possibilità di una cosa del genere accada è astronimically piccolo dato il tempo necessario per accedere a un file attraverso la rete (che limita strongmente il numero di operazioni al secondo che puoi fare). Questo è molto diverso da ad es. qualcuno che impone un hash da un database di password rubato, in cui l'hacker in genere prova centinaia di milioni di hash al secondo.
Probabilmente avrai più probabilità di morire per essere stato colpito da una meteora piuttosto che vederlo nella tua vita.

Inoltre, un rapido Google dice che S3 supporta le cartelle, quindi se sei in modalità ultra-paranoia, puoi creare una cartella con un nome UUID e inserire lì i file con nome UUID. Qualcuno dovrebbe indovinare correttamente un numero a 256 bit per accedere a un file, puoi essere abbastanza sicuro che questo non accadrà durante la tua vita.

    
risposta data 16.03.2014 - 13:14
fonte

Leggi altre domande sui tag