Perché srand (time()) è un cattivo seme?

Question

L'utilizzo di srand(time()) per generare un token per la reimpostazione della password (o per un token CSRF) non è corretto perché il token può essere prevedibile.

ho letto queste:

• Is using microtime() to generate password-reset tokens bad practice

• REST Web Service authentication token implementation

Ma io non capisco come il token può essere prevedibile. Capisco che se in un secondo resento la mia password molte volte ottengo lo stesso token. Ho il seguente codice:

<?php 

srand(time()); 
$reset_password_token = rand(444444444444,999999999999); 

?> 

Se reimposta la password di molte volte in un secondo, so che ho la stessa ragione, ma come può un hacker può sfruttare questa?

Answer 1

Limita l'ambito della loro forza bruta. Ad esempio, devono solo tentare solo 60 password se sanno che qualcuno ha effettuato un reset nell'ultimo minuto.

Ma è peggio di così. L'utente malintenzionato può accedere a qualsiasi account desiderato avviando una reimpostazione della password per tale account. Dopo questo, generano alcuni token chiamando ripetutamente srand con il timestamp unix per una piccola finestra di tempo attorno al reset, incrementando ogni volta. Uno di quei token deve corrispondere a meno che il tuo orologio non sia lontano.

Answer 2

tempo di attacco telaio

L'attaccante può conoscere/indovinare l'ora del vostro sistema. Ovviamente un hacker non può conoscere il secondo esatto perché per la maggior parte dei server può differire un po '.

Ma dicono per esempio il vostro tempo locale è:

> echo time(); 
1431212010 

allora si può fare una "buona congettura" che il seme sarà situato tra il 1431212005 e 1431212015.

Quindi, se si possono fare 10 ipotesi, è molto probabile che la password sia corretta.

Ovviamente l'hacker deve ancora conoscere l'algoritmo che "genera" la password. Ma per la maggior parte dei sistemi, è piuttosto semplice e, inoltre, come sempre nella sicurezza, è meglio che non si sappia molto del sistema. Dopo tutto, la maggior parte degli hacker può creare il proprio account e "ispezionare" come viene generata la password e cercare prima i modelli.

Se l'hacker ha un account lui/lei

Un modo davvero conveniente per incidere quelli della password viene inoltre inviare due richieste di reimpostazione della password a circa nello stesso momento: dire che hai un account X e si vuole incidere conto Y. Entro un millisecondo, puoi inviare due richieste, una per te e l'altra per la vittima. Successivamente si riceve la password e è possibile utilizzarla per entrambi gli account. Come dice @AlfredRossi, puoi inoltre elencare su tutti gli account del sito web e quindi hackerare la maggior parte degli account.

Solutions

La maggior parte dei sistemi offrono un modo per generare "reale casuale" (ovviamente è discutibile se si parla di vero e proprio casuale).Ad esempio catturando il rumore nei canali audio o ascoltando altri "rumori". Questi valori sono meno prevedibili poiché è difficile indovinare quale sia l'intensità misurata su un canale audio a poche migliaia di miglia dalla sua posizione.

Answer 3

buone soluzioni

questo presuppone è necessario un nonce a 256 bit.

1. random_bytes(32) (PHP 7.0.0+)
2. openssl_random_pseudo_bytes(32)
3. mcrypt_create_iv(32, MCRYPT_DEV_URANDOM)
4. Lettura da /dev/urandom

Codice snippet 4 #:

<?php 
function getRandom($bytes) 
{ 
    // Read only, binary safe mode: 
    $fp = fopen('/dev/urandom', 'rb'); 

    // If we cannot open a handle, we should abort the script 
    if ($fp === false) { 
     die("File descriptor exhaustion!"); 
    } 
    // Do not buffer (and waste entropy) 
    stream_set_read_buffer($fp, 0); 

    $entropy = fread($fp, $bytes); 
    fclose($fp); 
    return $entropy; 
} 

Bad Solu zioni

• mt_rand()
• rand()
• uniqid()
• microtime(true)
• lcg_Value()

Che cosa rende una buona soluzione?

Una buona soluzione dovrebbe sfruttare un generatore di numeri pseudocasuali crittograficamente sicuro (CSPRNG). Sui sistemi operativi basati su Unix, questo può essere ottenuto leggendo direttamente da /dev/urandom.

Ma non capisco come il token possa essere prevedibile.

Questo argomento è stato trattato in modo approfondito prima.

• Pwning RNGs (PDF)
• Predicting Random Numbers in PHP - It's Easier Than You Think
• Insufficient Entropy for Random Values

Ho il seguente codice:

<?php 

srand(time()); 
$reset_password_token = rand(444444444444,999999999999); 

?> 

In teoria, ci sarebbe essere solo 555555555555 valori possibili per questo. Sfortunatamente, il numero attuale è molto inferiore a.

rand() utilizza un algoritmo chiamato Linear Congruent Generator, che a causa di come è implementato in PHP 5, funziona solo con numeri interi a 32 bit senza segno. Entrambi i numeri forniti sono maggiori di 2**32. Non sono sicuro che potrebbe traboccare. The source code non è molto illuminante in questo caso.

Tuttavia, poiché si stanno seminando i numeri casuali con time(), si incontreranno dei problemi. Rapidamente, eseguire questo codice:

<?php 

srand(1431223543); 
echo rand()."\n"; 

Si dovrebbe vedere 1083759687 nella tua console. In generale, la differenza di tempo tra i computer su Internet è piuttosto piccola. Probabilmente potresti tenere conto solo di un possibile jitter fino a 2 secondi in ogni fuso orario, e ci vorranno solo 120 ipotesi (caso peggiore) per iniziare a prevedere l'output di numeri casuali. Per sempre.

Per qualsiasi motivo relativo alla sicurezza dell'applicazione, utilizzare un CSPRNG.

Answer 4

Se reimpostare la mia password molte volte in un secondo, so che ottengo lo stesso token ma come un utente malintenzionato può sfruttarlo?

Hai la cosa che un aggressore deve "fare molti" di sbagliato. Un utente malintenzionato può generare i propri token per molti secondi diversi e provarli tutti contro il tuo account.