it-swarm-eu.dev

I GUID sono sicuri per i token una tantum?

Vedo che molti siti utilizzano GUID per reimpostare password, richieste di annullamento dell'iscrizione e altre forme di identificazione univoca.

Presumibilmente sono attraenti perché sono facili da generare, unici, non sequenziali e sembrano casuali.

Ma sono abbastanza sicuri per questi scopi?

Mi sembra che dato un GUID, prevedere i GUID successivi possa essere possibile poiché (per quanto ne so) non sono destinati a essere crittograficamente sicuri ... o lo sono?

Nota:

  • Non sto non parlando di siti che usano un blob casuale di gobbledygook codificato in base64.
  • Sto parlando di siti come questo che sembrano utilizzare una guida non elaborata:
    http://example.com/forgotPassword/?id=b4684ce3-ca5b-477f-8f4d-e05884a83d3c
84
Michael Haren

Sono abbastanza sicuri per gli scopi che hai descritto? Secondo me, generalmente sì. Sono abbastanza sicuri nelle applicazioni in cui la sicurezza è una preoccupazione significativa? No. Vengono generati utilizzando un algoritmo non casuale, quindi non sono in alcun modo crittograficamente casuali o sicuri.

Quindi, per una funzione di verifica dell'iscrizione o della disiscrizione, non vedo davvero un problema di sicurezza. D'altro canto, per identificare un utente di un'applicazione di banking online (o molto probabilmente anche una funzione di reimpostazione della password di un sito in cui l'identità è preziosa) i GUID sono decisamente inadeguati.

Per ulteriori informazioni, è possibile consultare sezione 6 (Considerazioni sulla sicurezza) di RFC 4122 per GUID (o identificatori universalmente univoci).

42
Xander

specifica UUID specifica diverse "versioni" che sono metodi per generare l'UUID. La maggior parte mira a garantire l'unicità (che è il punto principale dell'UUID) utilizzando, ad esempio, la data corrente. Questo è efficiente ma significa che mentre gli UUID generati sono unici, sono anche prevedibili, il che li rende inadeguati per alcuni usi della sicurezza.

Il metodo di generazione UUID "versione 4" (nella sezione 4.4) , tuttavia, dovrebbe utilizzare un generatore di numeri casuali crittograficamente forte. 6 dei 128 bit sono fissati su un valore convenzionale (per indicare che si tratta di un UUID versione 4, vale a dire), quindi questo lascia 122 bit dall'RNG.

Se l'RNG sottostante è sicuro (ad es. /dev/urandom Su un sistema Linux/MacOS/* BSD o CryptGenRandom() su Windows) quindi dati molti UUID generati, un utente malintenzionato non dovrebbe essere in grado di prevedere il prossimo con probabilità di successo superiore a 2-122, che è sufficientemente piccolo per la maggior parte degli scopi, compresi i codici di lancio per i missili nucleari.

122 bit casuali garantiscono unicità con alta probabilità. Se generi molti UUID versione 4 e li accumuli, potresti aspettarti di incontrare la tua prima collisione dopo circa 261 UUID: sono circa 2 miliardi di miliardi; la semplice memorizzazione di quel numero di UUID richiederebbe oltre 30 milioni di terabyte. Se consideri "solo" 1012 tale UUID (mille di miliardi, memorizzabile su 16 terabyte), quindi i rischi di avere due UUID identici tra questi sono circa 9,4 * 10-14, cioè circa 700 mila volte meno probabile che vincere milioni di dollari alla lotteria.

Pertanto, UUID are appropriato per motivi di sicurezza if (e solo se) sono UUID "versione 4" generati con un RNG sicuro.

59
Thomas Pornin

Sono sicuri su Windows 2000 o successivi. La vulnerabilità e il rischio dipendono da come viene generato il GUID. Windows 2000 o più recente utilizza la versione 4 del GUID che è crittograficamente sicuro.

Per ulteriori informazioni, vedere questo collegamento MSDN e questo domanda di overflow dello stack . (Grazie a Jordan Rieger nei commenti)

5

Se stai usando un linguaggio di sviluppo comune creando un generatore one shot di numeri casuali univoci utilizzando una corretta funzione di crittografia non è così difficile (stiamo parlando di 10 righe di codice che sono disponibili come esempi nelle lingue più comuni semplicemente usando Google ) e quindi l'utilizzo di un semplice nuovo guid è sostanzialmente pigrizia dal punto di vista degli sviluppatori.

Nello scenario descritto sono "abbastanza sicuri", se il Guid passato nella funzione password dimenticata ha alcune funzionalità di base:

1) È davvero un valore one shot che non ha alcuna relazione con l'id utente, quindi, una volta ripristinata la password, non può più essere utilizzata

2) Ha una finestra temporale definita per la sua validità (puoi reimpostare la password nei prossimi 30 minuti o qualcosa del genere)

Se si utilizza lo stesso Guid è possibile reimpostare la password più di una volta o indovinare la guida e reimpostare la password degli utenti che non hanno richiesto il ripristino della password o, come Avid descrive nel commento, provare ad accedere per ripristinare la password utilizzando un tipo di replay attach, allora il design dell'applicazione è difettoso e l'utilizzo o meno di un Guid non è il vero problema.

Quindi, se non hai a che fare con informazioni molto sensibili, allora forse un guid potrebbe funzionare, ma perché non creare le cose in modo corretto la prima volta e usare una crittografia API adeguata per generare una stringa casuale sicura?

Saluti Massimo

3
massimogentilini

"GUID" falsi, che sono not generati da qualsiasi GUID, ma che invece sono semplicemente 128 bit (16 byte) generati da un PRNG crittograficamente sicuro, e che sono semplicemente rappresentati usando la codifica convenzionale GUID hex-with-hyphens, sono per lo più sicuri per i token una tantum.

Ti imbatti nel problema del compleanno, tuttavia, poiché l'esistenza di una collisione è di circa 2 ^ -64 per i token a 128 bit.

Meglio usare token a 256-bit o 512-bit, dove l'esistenza di una collisione è di circa 2 ^ -128 o 2 ^ -256.

0
yfeldblum