Diciamo che voglio creare un cookie per un utente. Genererebbe semplicemente una stringa bit 1024 utilizzando / dev / urandom e verificando se esiste già (il looping fino a quando ne ottengo uno unico) è sufficiente?
Dovrei generare la chiave sulla base di qualcos'altro? In qualche modo questo è soggetto a un exploit?
La risposta breve è sì. La lunga risposta è anche sì. /dev/urandom produce dati che sono indistinguibili dalla casualità vera, data la tecnologia esistente. Ottenere una casualità "migliore" rispetto a quanto fornito da /dev/urandom non ha senso, a meno che non si stia utilizzando uno dei pochi algoritmi crittografici "teorici dell'informazione", che non è il tuo caso (lo sapresti).
La pagina man per urandom è in qualche modo fuorviante, probabilmente decisamente errata, quando suggerisce che /dev/urandom potrebbe "esaurire l'entropia" e /dev/random dovrebbe essere preferito; l'unico istante in cui /dev/urandom potrebbe implicare un problema di sicurezza dovuto a bassa entropia è durante i primi momenti di una nuova installazione automatica del sistema operativo; se la macchina si è avviata fino a un punto in cui ha iniziato ad avere attività di rete, ha raccolto abbastanza casualità per fornire casualità di qualità abbastanza elevata per tutti gli usi pratici (sto parlando di Linux qui, su FreeBSD, quell'istante momentaneo di lieve la debolezza non si verifica affatto). D'altra parte, /dev/random ha la tendenza a bloccare in tempi inopportuni, causando problemi di usabilità molto reali e fastidiosi. Oppure, per dirlo in parole povere: usa /dev/urandom e sii felice; usa /dev/random e si dispiace.
( Modifica: questa pagina Web spiega le differenze tra /dev/random e /dev/urandom abbastanza chiaramente.)
Allo scopo di produrre un "cookie": tale cookie dovrebbe essere tale che nessuno degli utenti condivida lo stesso cookie e che sia computazionalmente impossibile da parte di chiunque "indovinare" il valore di un cookie esistente. Una sequenza di byte casuali funziona bene, a condizione che utilizzi casualità di qualità adeguata ( /dev/urandom va bene) e che è abbastanza lungo . Come regola generale, se hai meno di 2 n utenti ( n = 33 se l'intera popolazione terrestre potrebbe utilizzare il tuo sistema), quindi una sequenza di bit n + 128 è sufficientemente ampia; non è nemmeno necessario verificare una collisione con valori esistenti: non la vedrai nel corso della tua vita. 161 bit si adattano a 21 byte.
Ci sono alcuni trucchi che sono fattibili se vuoi biscotti più corti e desideri ancora evitare di cercare collisioni nel tuo database. Ma questo dovrebbe essere difficilmente necessario per un cookie (presumo un contesto basato sul Web). Inoltre, ricorda di mantenere riservati i tuoi cookie (ad esempio, utilizza HTTPS e imposta i cookie "sicuro" e "HttpOnly").
Sì, è un ottimo modo.
@ La spiegazione di Thomas lo inchioda. E ha perfettamente ragione nel criticare la pagina man di /dev/urandom . Spot on.
Ma salta "controllando se esiste già". Quel controllo è inutile. Non succederà. (Le probabilità che ciò accada sono inferiori alla probabilità di essere colpiti da un fulmine - più volte - nello stesso giorno.)
Fai attenzione ai casi limite se stai usando Linux o NetBSD.
Su Linux, dovresti assicurarti di avere abbastanza entropia dopo l'avvio per seminare correttamente CSPRNG, o usare getrandom() chiamata di sistema per leggere da /dev/urandom e solo blocco nell'evento raro che non sia disponibile un'entità di seme iniziale post-avvio sufficiente.
In NetBSD, vorrai leggere da /dev/random almeno una volta prima di leggere da /dev/urandom per assicurarti che sia stato seminato correttamente.
Su FreeBSD e MacOS non ci sono differenze tra /dev/random e /dev/urandom .
La risposta breve deve ancora usare /dev/urandom .
Vedi Quando utilizzare / dev / random vs / dev / urandom per ulteriori dettagli.
Da link "Generare una vera entropia in un computer è abbastanza difficile perché nulla, al di fuori della fisica quantistica, è casuale. Il kernel di Linux usa tastiera, mouse, attività di rete e disco, con un algoritmo crittografico (SHA1), a generare dati per il dispositivo / dev / random. Uno dei problemi con questo è quello l'input non è costante, quindi il pool entropy del kernel può facilmente diventare vuoto. " "Un altro problema con l'utilizzo della tastiera, del mouse, della rete e dell'attività del disco è che su sistemi inattivi, senza personale e senza dischi vi è un input molto piccolo o inesistente di questo tipo. "
Per me sembra possibile che / dev / urandom si esaurisca perché / dev / random lo alimenta.
Leggi altre domande sui tag linux random authentication cryptography web-application