Utilizzo dell'UUID V4 per l'autenticazione

Gli UUID generalmente non garantiscono l'imprevedibilità o proprietà di sicurezza. Come dice RFC 4122 (sezione 6):

Do not assume that UUIDs are hard to guess; they should not be used as security capabilities (identifiers whose mere possession grants access), for example. A predictable random number source will exacerbate the situation.

Quello che ti serve qui è un generatore di numeri casuali crittograficamente sicuro . Alcune implementazioni UUID sono scacciate da tali RNG, ma questa è una scelta di implementazione, non una garanzia. Lo standard ITU afferma esplicitamente che l'uso del numero casuale crittografico è < strong> consigliato , che implica chiaramente che non è un requisito (pagina 10):

The use of cryptographic-quality random numbers is strongly recommended in order to reduce the probability of repeated values.

E si scopre che alcune implementazioni UUID non sono sicure. Ad esempio, almeno alcune versioni del motore JavaScript V8 di Google utilizzano un PRNG non crittografico per la generazione UUID casuale . Il collegamento descrive come attaccare tali UUID: con un paio di righe di codice, un utente malintenzionato che vede un tale UUID può ricostruire lo stato del PRNG quando emette quell'UUID, che consente loro di prevedere tutti gli UUID successivi.

Quindi non userei gli UUID come segreti crittografici: mi interfaccia direttamente con l'RNG crittografico, almeno per rendere evidente l' intento del codice.

Il problema più grande è che i tuoi utenti non sarebbero in grado di ricordare tali token; avrebbero dovuto metterli da qualche parte al sicuro e non avresti fornito assistenza per farlo. L'alternativa non ovvia ma in realtà molto naturale qui è quella di utilizzare un sistema di autenticazione a più fattori basato su password e chiavi segrete, come TOTP . Ad esempio, se crei un'integrazione con Google Authenticator o Authy , i tuoi utenti ottengono il vantaggio delle app lato utente di tali fornitori per archiviare e gestire la chiave segreta condivisa.

Stai solo descrivendo uno schema in cui l'UUID diventa semplicemente una password.

Non c'è nulla di particolarmente sicuro o insicuro su questo, a parte il fatto che nessuna persona sarà mai in grado di scegliere una password "debole", ma d'altra parte, la metà delle persone sta per memorizzare la propria password non crittografata.

Non vedo davvero perché lo faresti alle persone. Non ti renderai molto popolare negando ai dilettanti la possibilità di scegliere una password che possono ricordare, né agli esperti la possibilità di crearne uno che si ritenga sicuro.

Inoltre, personalmente penso che le password dei singoli conti bancari valgano molto meno (considerando che le banche sono state bonifici a 2 factoring, almeno in Europa, da oltre 25 anni con ID transazione una sola volta pads) rispetto al controllo di dominio (non posso rovinare l'attività di qualcuno guardando il suo conto in banca a meno che non intendo usarlo per pasticciarlo in base ad altre informazioni, ma posso facilmente rovinarlo reindirizzando tutte le sue e-mail attraverso i miei server manipolando il Record MX del loro dominio, e in modo selettivo lasciare che il CEO metta la posta e rispondere al loro posto. Oh, e sai, se hanno un business online, abusano della loro presenza sul web nella misura massima).

Given the above, is this still a bad idea?

Sì, inventare nuovi schemi di autenticazione è di solito una cattiva idea.

Do you think this is less secure than username / pass?

Dipende dai tuoi clienti e, come al solito, nello scenario di attacco.

Would slamming two UUIDs together be more secure?

Porterebbe a sequenze casuali più lunghe, quindi sì, ma allora, perché non usare una sequenza casuale più lunga dall'inizio?

Sembra tutto come se non ci avessi pensato.