I GUID sono sicuri per i token una tantum?

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

Quindi, per una funzione di annullamento dell'iscrizione o di sottoscrizione, non vedo davvero un problema di sicurezza. D'altra parte, identificare un utente di un'applicazione bancaria online (o probabilmente anche una funzione di reimpostazione della password di un sito in cui l'identità è preziosa) i GUID sono decisamente inadeguati.

Per ulteriori informazioni, puoi consultare la sezione 6 (Considerazioni sulla sicurezza) della RFC 4122 per GUID (o identificatori universalmente univoci).

La specifica UUID descrive diverse "versioni" che sono metodi per generare l'UUID. La maggior parte mira a garantire l'unicità (questo è 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 di sicurezza.

Il "4" metodo di generazione UUID (nella sezione 4.4) , tuttavia, dovrebbe utilizzare un generatore di numeri casuali crittograficamente strong. 6 dei 128 bit sono fissati su un valore convenzionale (per indicare che questo è un UUID versione 4, ovvero), quindi questo lascia 122 bit dal RNG.

Se l'RNG sottostante è sicuro (ad es. /dev/urandom su un sistema Linux / MacOS / * BSD, o CryptGenRandom() su Windows) allora dato molti UUID generati, un utente malintenzionato non dovrebbe essere in grado di predire 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 assicurano l'unicità con alta probabilità. Se generi più UUID versione 4 e li accumuli, potresti aspettarti di incontrare la tua prima collisione dopo circa 2 ⁶¹ UUID - che è di circa 2 miliardi di miliardi; semplicemente memorizzando quel numero di UUID si userebbero più di 30 milioni di terabyte. Se consideri "solo" 10 ¹² tale UUID (un miliardo di miliardi, memorizzabile oltre 16 terabyte), allora i rischi di avere due UUID identici tra questi sono circa 9.4 * 10 ^-14 , cioè circa 700 migliaia di volte meno probabile di vincere milioni di dollari alla lotteria.

Pertanto, UUID sono appropriati per scopi di sicurezza se (e solo se) sono UUID "versione 4" generati con un RNG sicuro.

Sono sicuri su Windows 2000 o successivi. La tua vulnerabilità e amp; il rischio dipende da come viene generato il GUID. Windows 2000 o versione successiva utilizza la versione 4 del GUID che è crittograficamente sicuro.

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

Se stai utilizzando un linguaggio di sviluppo comune per creare un generatore one shot di numeri casuali univoci utilizzando una funzione crittografica appropriata non è così difficile (stiamo parlando di 10 righe di codice che sono disponibili come campioni nelle lingue più comuni semplicemente usando Google) e quindi usando un semplice nuovo guid è praticamente pigrizia dal punto di vista dello sviluppatore.

Nello scenario descritto sono "abbastanza sicuri", se la guida passata nella funzione password dimenticata ha alcune caratteristiche di base:

1) È davvero un valore one shot che non ha alcuna relazione con l'id utente, quindi, una volta resettata 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 la stessa guida è possibile reimpostare la password più di una volta o indovinare la guida e reimpostare la password degli utenti che non hanno richiesto la reimpostazione della password o, come Avid descrive nel commento, provare ad accedere alla reimpostazione della password utilizzando una sorta di replay allegare quindi è il design dell'applicazione che è 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 fare le cose in modo corretto la prima volta e usare una crypto api corretta per generare una stringa casuale sicura?

Saluti Massimo

Finti "GUID", che sono non generati da qualsiasi algoritmo di generazione GUID, ma che invece sono semplicemente 128 bit (16 byte) generati da un PRNG crittograficamente sicuro e che sono rappresentati semplicemente usando la codifica GUID hex-with-hyphens convenzionale, è quasi sicura per i token di una volta.

Esegui il problema del compleanno, tuttavia, poiché l'esistenza di una collisione è intorno a 2 ^ -64 per i token a 128 bit.

È meglio utilizzare token a 256 o 512 bit, in cui l'esistenza di una collisione è intorno a 2 ^ -128 o 2 ^ -256.