Sali password e casualità

Questo sembra fuorviante.

Il tempo in secondi di qualsiasi sorgente manca praticamente di qualsiasi entropia, ed è quasi immediatamente ipotizzabile. Se il tuo sistema operativo consente la granularità del microsecondo per un processo in esecuzione, otterrai 4 o 5 bit di entropia, dai bit più bassi, ma molto meno se qualcuno trova un modo per ottenere il tempo di funzionamento esatto del sistema.

Quindi stai parlando di MD5, che in questo caso non è molto utile. Tutto ciò ti dà la impressione che hai reso più casuale, senza renderlo casuale. In realtà hai solo un paio di interi che dipendono l'uno dall'altro (il tempo di elaborazione sarà sempre sincronizzato con l'uptime del sistema) e che sono completamente non casuali. Il tuo sistema quasi certamente perde il tempo di attività in un modo o nell'altro. In realtà starai meglio usando un LCG come %% di% di PHP, poiché lo stato interno non può essere indovinato come facilmente.

Questo approccio alla generazione casuale di numeri è sbagliato, perché non è affatto casuale e può essere previsto. Tuttavia, i sali in realtà non devono essere particolarmente casuali, devono solo essere unici; sono lì solo per prevenire gli attacchi dei tavoli arcobaleno. L'imprevedibilità aiuta (vedi "come conservare il sale?" ) ma isn 't interamente richiesto. Indipendentemente da ciò, ci sono alcuni vantaggi nel rendere difficile la previsione del sale.

Se sei su Linux, leggi alcuni byte da rand() per generare il sale - non devi fare altro che prendere quei byte e usarli, perché sono già numeri casuali forti.

In caso contrario, potresti generare il sale come /dev/urandom dove SHA256(username || email || time || mt_rand()) denota concatenazione, || è l'ora corrente del sistema in un resoluton alto come puoi ottenere, e time è un valore di uscita da qualunque il generatore casuale è disponibile nella libreria predefinita del linguaggio di programmazione. In PHP dovresti usare mt_rand() piuttosto che mt_rand , poiché ha caratteristiche migliori. Questo fornisce abbastanza entropia per un sale è molto difficile da indovinare da remoto, soprattutto date le limitate opportunità di riutilizzo delle combinazioni di nome utente ed e-mail.

Per memorizzare la password, dovresti sicuramente usare PBKDF2 o bcrypt. Un singolo utilizzo di una funzione di hash crittografica non è sufficiente per proteggersi dagli attacchi bruteforce, specialmente quando quasi tutti hanno una GPU compatibile con OpenCL al giorno d'oggi.

In realtà, un sale non deve essere casuale; deve essere unique . Questa è l'unicità in tutto il mondo (unica per tutti i tempi e per tutti i server in tutto il mondo), e il modo più semplice per raggiungere l'unicità è usare la casualità: generare 16 byte (o più) con un generatore casuale crittograficamente strong e la probabilità di raggiungere un valore di sale che è già stato utilizzato altrove è sufficientemente piccola da essere trascurata.

La casualità è difficile. Quello che presenti è la combinazione di un generatore di numeri casuali deboli fatto in casa e un meccanismo di hashing delle password deboli fatto in casa. Il modo corretto per generare un salt è chiedere al generatore di numeri pseudocasuali di farlo per te ( /dev/urandom su sistemi Unix-like, CryptGenRandom() su Windows, System.Security.Cryptography.RNGCryptoServiceProvider su .NET. ..). Quindi , usa il sale con un corretto sistema di hashing della password come bcrypt o PBKDF2 . La maggior parte delle implementazioni di bcrypt in realtà farà la generazione di sale per te, quindi è ancora meglio.