Non sono a conoscenza di alcun attacco pubblicamente noto sulla previsione dell'output futuro di /dev/urandom , indipendentemente dalla quantità di dati precedenti che hai già visto. Sarebbe possibile in teoria, però, che un tale attacco esista. Se un tale attacco esiste, richiederà quasi certamente vaste quantità di output per fare una previsione. Probabilmente molti più dati di quelli che un utente malintenzionato sarebbe in grado di estrarre senza far cadere prima il server o la rete.
Ci sono alcuni altri fattori che funzionano a tuo favore e contro un ipotetico aggressore.
Il pool entropico di Linux è alimentato da eventi non deterministici come il timing dei pacchetti di rete. Per interrogare il tuo server, un utente malintenzionato deve creare il traffico di rete. Dal momento che il traffico andrà su più router che non sono sotto il controllo dell'attaccante, sembra altamente improbabile che siano in grado di prevedere i tempi di arrivo in modo affidabile. Pertanto, l'attacco sconfigge se stesso riempiendo la riserva di entropia mentre tenta di scaricarla.
Le moderne CPU x86 hanno istruzioni speciali (RDRAND) per recuperare l'entropia fisica a un ritmo estremamente alto. Come la documentazione Intel dice,
The [all-digital Entropy Source] runs asynchronously on a self-timed circuit and uses thermal noise within the silicon to output a random stream of bits at the rate of 3 GHz.
Mentre una CPU veloce può consumare parole casuali a un ritmo ancora più elevato, nel qual caso la CPU ricade su un generatore parzialmente deterministico, è lecito ritenere che l'applicazione non invierà dati critici a oltre 358 MiB / s (equivalente a 3 × 10 9 bit al secondo).
Il pool entropico di Linux si mescola nell'entropia ottenuta da RDRAND dove è disponibile. Questo è fatto in modo intelligente in modo tale che anche nel abbastanza plausibile caso puramente cospirativo che Intel abbia messo una backdoor in RDRAND su richiesta del governo, non sarebbe peggio che se il dispositivo non fosse affatto utilizzato e probabilmente ancora aiuti un po '.
In conclusione, non penso che prosciugare il tuo pool di entropia sia qualcosa su cui dovresti preoccuparti troppo a questo punto. Se lo sei ancora, ci sono modi meno invasivi rispetto al fatto che i tuoi utenti risolvano i CAPTCHA.
Per esempio, potresti limitare artificialmente il tuo generatore di codice. Se consenti solo, ad esempio, un codice al secondo e IP, il tuo servizio sarà comunque abbastanza veloce per l'uso legittimo, ma renderà l'estrazione considerevolmente più difficile.
Inoltre, nota che /dev/random e /dev/urandom non sono solo leggibili ma anche scrivibili. Dalla pagina man :
Writing to /dev/random or /dev/urandom will update the entropy pool with the data written, but this will not result in a higher entropy count. This means that it will impact the contents read from both files, but it will not make reads from /dev/random faster.
Quindi, invece di mostrare CAPTCHA ai tuoi utenti, potresti scriverlo su /dev/urandom . Naturalmente, questo ha senso solo se CAPTCHA è stato generato su un altro computer, ad esempio quando si utilizza un servizio come reCAPTCHA . Questo consiglio è ovviamente da prendere con un pizzico di sale. Avrebbe probabilmente più senso aggiornare il tuo pool di entropia con i dati ottenuti da un servizio come RANDOM.ORG .
La cosa che dovrebbe essere preoccupata è che se il tuo server è stato appena avviato, il pool entropico interno potrebbe non essere ancora riempito. In questo caso, la lettura da /dev/urandom fornirà una scarsa entropia. Un trucco per evitare questo è di fare in modo che l'applicazione inizialmente legga un singolo byte da /dev/random che bloccherà fino a quando il sistema non avrà raccolto un po 'di entropia. Sui sistemi che hanno RDRAND (supponendo che non sia backdoor), questo problema di avvio sarà benevolo dato che RDRAND non ha bisogno di riscaldamento.
Se sviluppi la tua applicazione utilizzando una tecnologia in cui puoi effettuare chiamate alle funzioni della libreria C, Linux 3.17 e versioni successive fornisce getrandom syscall che dovrebbe essere preferito alla lettura da /dev/urandom in quanto funziona anche se /dev/urandom non è disponibile (ad esempio, perché l'applicazione è chroot() ed) e, altro importante, non soffre del problema di avvio che /dev/urandom ha. ( getrandom bloccherà fino a quando il pool di entropia non sarà inizialmente riempito.)
Un servizio come RANDOM.ORG può anche essere usato per mitigare la situazione di bassa entropia dopo l'avvio ma non dipenderei mai direttamente da un servizio di terze parti per generare i miei segreti casuali. Se vuoi essere sicuro, supponi che tutto ciò che scarichi sia deterministico e noto a un utente malintenzionato. (Nel caso in cui non sia ancora chiaro, la scrittura di tali dati su /dev/urandom non fa male. Non fa nulla di buono neanche.)