Strumenti per sviluppatori · Generatore UUID
Un UUID casuale è sicuro come la reimpostazione della password o il token di sessione?
· Perché è importante
uuid crittografia API del browser
Un UUID v4 da un CSPRNG ha molta entropia, quindi perché i revisori della sicurezza continuano a disapprovare i token UUID? Questo post separa la questione dell'entropia dalla questione del design.
Il collegamento di ripristino che utilizza UUID della riga: una scorciatoia comune e i due motivi molto diversi per cui potrebbe non essere sicuro
Una scorciatoia comune: utilizza l'identificatore di riga UUID dell'utente come token di reimpostazione della password. La tabella ha una colonna uuid; è unico; è difficile da indovinare (se è un v4). Il URL è /reset? token=550e8400-e29b-41d4-a716-446655440000. Un revisore della sicurezza lo rifiuta immediatamente, non perché UUID sia debole, ma perché unisce due preoccupazioni che dovrebbero essere indipendenti. La riga UUID è stabile e solitamente visibile pubblicamente (in URL, API, log). Il token di ripristino deve essere monouso e segreto. Riutilizzare la riga UUID come token significa che l'identità dell'utente e la credenziale reimpostata hanno lo stesso valore e la credenziale rimane per sempre invece di scadere. Un utente malintenzionato che conosce l'ID dell'utente può eseguire un ripristino. Un utente che ha copiato e incollato un collegamento di ripristino cinque anni fa può ancora utilizzarlo. Questi sono difetti di progettazione, non difetti di entropia.
Controllo dell'entropia: 122 bit casuali: perché un v4 generato da CSPRNG non è indovinabile dalla forza bruta
Il controllo della casualità è necessario ma non sufficiente. La versione 4 riserva quattro bit di versione e due bit di variante, lasciando 128 - 4 - 2 = 122 posizioni casuali quando l'implementazione riempie gli altri campi in modo casuale. Questa derivazione non dice nulla sulla scadenza, sulla conservazione o sull'autorizzazione. Il controllo del generatore chiede se tali campi provengono da CSPRNG anziché da Math.random o da un timestamp. ToolAcre soddisfa il limite del generatore. Il controllo di progettazione rimane specifico dell'applicazione: una credenziale reimpostata necessita di un ciclo di vita separato, una rappresentazione memorizzata unidirezionale, un invalidamento dopo un utilizzo riuscito e una scadenza scelta dalla politica di rischio del servizio. Il riutilizzo dell'ID record permanente dell'utente non consente tale separazione anche quando l'ID è stato generato in modo sicuro.
Controllo del generatore: dove i token UUID effettivamente falliscono: generazione basata su Math.random, timestamp v1 e indirizzi MAC e seed prevedibili
Un esempio funzionante: uno schema di reimpostazione della password che fallisce e poi supera i tre controlli. Non supera il controllo dell'entropia: il server emette un token di ripristino tramite Math.random(), imballato come v4 UUID. Un attaccante osserva tre gettoni e predice il quarto. Non supera il controllo del generatore: il server utilizza un UUID v1 come token di ripristino, includendo il timestamp di creazione e l'indirizzo MAC nel valore. Un utente malintenzionato legge il timestamp, apprende quando è stato effettuato il ripristino e restringe la finestra di ricerca. Supera il controllo di entropia ma fallisce il controllo di progettazione: il server utilizza un v4 UUID da crypto.getRandomValues, ma lo memorizza in testo semplice nel database e non imposta una scadenza. Un utente malintenzionato che viola il database legge i token di ripristino e li utilizza per ripristinare gli account settimane dopo. I tre controlli sono indipendenti; devi superarli tutti e tre.
Controllo di progettazione: identificatore rispetto a credenziale: perché riutilizzare la chiave primaria di un record come segreto accoppia due cose che dovrebbero ruotare indipendentemente
Uno schema di token di ripristino che supera i controlli di entropia e generatore ma non supera il controllo di progettazione (nessun hash, nessuna scadenza, nessun invalidamento per utilizzo) è ancora vulnerabile. Gestione del token lato server: quando un utente richiede la reimpostazione della password, genera un nuovo token casuale (non la riga UUID) da crypto.getRandomValues. Memorizza una rappresentazione unidirezionale anziché il valore presentato, imposta una scadenza specifica per la policy e invalida il record dopo un utilizzo riuscito. Quando l'utente fa clic sul collegamento, cerca l'utente tramite e-mail, recupera l'hash archiviato, confronta il token fornito con l'hash, controlla la scadenza ed esegui il ripristino solo se il token è valido e non è ancora scaduto. Invalidare immediatamente il token (eliminarlo o contrassegnarlo come utilizzato) in modo che non possa essere riutilizzato. Non registrare mai il token grezzo; registra solo l'ID utente e l'azione.
Gestione del token lato server: archivia un hash, imposta una scadenza, invalida l'utilizzo e non registra mai il valore non elaborato
Il token non dovrebbe mai apparire nei messaggi di errore o nel database a meno che non sia sottoposto a hashing. La progettazione dell'autenticazione completa va oltre l'ambito di un articolo UUID, ma i principi valgono: un token casuale 122 bit non è intrinsecamente un token di accesso. La casualità è la parte facile; il generatore ToolAcre ti fornisce UUID supportati da CSPRNG. La parte difficile è la progettazione: hashing prima dell'archiviazione, impostazione dei tempi di scadenza, invalidazione durante l'uso, prevenzione del riutilizzo di ID permanenti come segreti temporanei, verifica di chi ha avuto accesso a cosa e quando. Un revisore della sicurezza che approva uno schema di reset-link basato esclusivamente sull'entropia del token salta il resto dell'analisi. Uno sviluppatore che ritiene che un UUID supportato da CSPRNG sia sufficiente per un collegamento di reimpostazione della password senza hashing, scadenza e invalidamento sta sottovalutando la minaccia. La casualità difende dalle supposizioni; il design difende dalla riproduzione, dalla scadenza e dall'uso improprio.
Esempio funzionante: rivedere uno schema di ripristino del collegamento rispetto a ciascun controllo e riscrivere le parti deboli
Il generatore ToolAcre fa bene la parte della casualità; l'applicazione deve eseguire correttamente la parte di progettazione. Metti alla prova il tuo codice di reset-link rispetto a tutti e tre i controlli: utilizza CSPRNG (crypto.getRandomValues, crypto.randomUUID o una libreria di crittografia), non Math.random? Il token ha una scadenza? Il token viene sottoposto ad hashing prima dell'archiviazione? Il token viene invalidato dopo l'uso? Il codice evita di riutilizzare l'ID permanente dell'utente come token temporaneo? Se rispondi sì a tutte queste domande, il design del tuo collegamento di ripristino è valido. Il generatore ToolAcre è la parte CSPRNG; il resto è codice dell'applicazione che è necessario esaminare attentamente. Comprendere i tre livelli di sicurezza ti aiuta a controllare librerie e framework UUID di terze parti. Quando valuti una libreria, controlla che utilizzi un CSPRNG (controllo dell'entropia), non una fonte casuale debole. Verificare che documenti quali fonti utilizza e perché (controllo del generatore).
Ciò che questo non copre: progettazione dell'autenticazione completa, MFA e limitazione della velocità, che contano tanto quanto l'entropia del token
Verificare che il codice di esempio e la documentazione enfatizzino i principi di progettazione: hashing, scadenza, invalidazione (controllo della progettazione). Le biblioteche che superano tutti e tre i controlli sono rare; la maggior parte si concentra solo sull’entropia. Il generatore ToolAcre supera i controlli di entropia e generatore utilizzando crypto.getRandomValues. La verifica della progettazione è a tuo carico; la libreria non può conoscere i requisiti di scadenza o la strategia di hashing. Il debug di un sistema di collegamento di ripristino interrotto di solito rivela uno dei tre errori. Se gli utenti segnalano di aver ricevuto collegamenti di reimpostazione che non funzionano più, il problema probabile è la scadenza: il token è stato emesso ma è scaduto prima che l'utente facesse clic sul collegamento. Se i token vengono riutilizzati più volte, l'invalidazione viene interrotta. Se i token vengono visualizzati nei messaggi di errore o nell'output di debug, la registrazione li perde. Se i collegamenti di reimpostazione funzionano per un utente ma non per un altro, potrebbero verificarsi ritardi di replica del database o problemi di fuso orario con il calcolo della scadenza. Se le richieste di ripristino legittime falliscono in modo casuale, CSPRNG potrebbe essere rotto (raro).
Conclusione: la casualità è la parte facile: il generatore ToolAcre ti fornisce UUID supportati da CSPRNG; il resto è disciplina del design
Inizia con la registrazione: abilita log di controllo dettagliati per la generazione e la verifica del ripristino del collegamento, quindi riproduci il problema e traccia il flusso. Il generatore ToolAcre garantisce il superamento dei primi due controlli; la risoluzione dei problemi di ripristino del collegamento rientra quasi sempre nella categoria della progettazione. Le migliori pratiche per i sistemi di collegamento di ripristino della produzione includono: generare un nuovo token casuale per ogni richiesta di ripristino, non riutilizzare i vecchi token. Archivia una rappresentazione unidirezionale insieme all'account e ai metadati di creazione, quindi scegli una scadenza dalla politica di rischio documentata del servizio. Invalidare il token immediatamente dopo la verifica riuscita. Registra le richieste di reimpostazione e i successi per il controllo. Implementare la limitazione della velocità per prevenire attacchi di forza bruta. Invia collegamenti di reimpostazione solo tramite email, non SMS o canali non crittografati. Notificare all'utente i tentativi di reimpostazione della password (in modo che possano rilevare reimpostazioni non autorizzate). Il generatore ToolAcre ti dà la casualità; seguire queste pratiche ti dà la sicurezza.