Come faccio a dimostrare che .NET class Random non è adatto alla generazione di password?

Question

Molto spesso vedo .NET class Random utilizzato per la generazione di password.

Da una parte, this question I asked earlier indica che la generazione di una serie di dati "segreti" utilizzando class Random produce dati piuttosto prevedibili. D'altra parte, sto attualmente cercando di eseguire quella previsione esatta e il mio codice funziona alla velocità di circa sei milioni di tentativi di semi al giorno su un singolo core - non estremamente veloce, ci vorrà quasi un anno per enumerare tutti i possibili valori di seme a quel ritmo.

Esiste un modo più chiaro e veloce per mostrare che le password generate utilizzando i dati da class Random() sono molto più deboli di quanto previsto in genere?

Answer 1

Dalla mia comprensione, la classe Random genera valori casuali basati su un "algoritmo di Psuedo-random", quindi in realtà non sono casuali come sempre. si basano su un'implementazione concreta di un algoritmo matematico, quindi i risultati sono prevedibili.

Quindi, se stavo cercando di rompere questo algoritmo, per una violazione della sicurezza, non che lo farei, ho bisogno di conoscere alcune informazioni: so qual è l'algoritmo, è pubblicamente accessibile attraverso il framework .Net, qual è il valori di input (il seme)?

Anche in questo caso non è possibile aumentare la magia di questi valori di input, devono essere basati su qualcosa, quindi cosa?

Nel tuo esempio il tuo tentativo, a quanto ho capito, di generare tutti i possibili valori di seme. Questo come hai detto richiede molto tempo!

Ma perché dovrei farlo? l'approccio più intelligente è cercare di indovinare cosa usi per generare i tuoi valori di input? cioè stai usando il tempo? Quando vengono ripristinate le password? Quando è stata generata questa password? Quale sottoinsieme di valori mi dà questo? Quanto grande è il numero che stai usando?

Se è possibile testare 6 milioni di semi in un giorno, quanti valori applica una certa logica restringono l'insieme di valori possibili fino a? Se è < 6 milioni potrei rompere la password in 24 ore.

Detto questo, se riesci a rendere il tuo sottoinsieme di semi abbastanza grande e imprevedibile, allora è difficile. Quindi la domanda, come fanno molte cose in sicurezza, quanto deve essere sicuro? Niente è al 100%!

Answer 2

Nella tua domanda originale nessuno dice che Random non sia buono per generare password casuali (infatti la parola "password" non appare in nessuna parte della domanda, delle risposte o dei commenti). Sarà difficile dimostrarlo perché, per fare ciò, il sistema dovrà generare contemporaneamente un numero di password casuali. Inoltre, l'utente malintenzionato dovrà in qualche modo corrispondere a nome utente e password anche se riuscirà a ottenere un buon numero di password.

Answer 3

Lasciatemelo dire in questo modo: selezionare un generatore di numeri casuali adeguato al numero di password che si desidera generare. Con una dimensione alfabetica di 36 (cifre e solo lettere maiuscole o minuscole) si estrae solo una piccola frazione dello stato interno del RNG. E anche se generi in questo modo 40000 caratteri, sono ancora solo circa 21 bit di informazione. L'algoritmo nell'altra domanda genera solo 4 caratteri casuali oltre al prefisso. Sarebbe più semplice per un utente malintenzionato forzare tutte le password possibili, anziché forzare lo stato RNG, in modo da capire la prossima password da generare.

In realtà, l'errore peggiore che si possa fare quando si utilizza un semplice RNG per generare password è di generarne un gran numero. Se li si genera solo su richiesta e sempre con un RNG appena seminato, un utente malintenzionato avrà difficoltà a capire il seme e quindi la password. L'implementazione predefinita di System.Random richiede il tempo trascorso dall'avvio del sistema in millisecondi come seme. Buona fortuna a pensarci.