Modo corretto per generare i salti delle password in PHP 5.3 su Linux dati i miei limiti?

3

Nell'esaminare la memoria del nostro database di password hash con sali, noto un alto tasso di collisioni saline, cioè, ci sono troppi casi in cui due righe di tabella hanno lo stesso sale memorizzato.

Una soluzione è iniziare immediatamente a generare sali "migliori" man mano che memorizziamo nuove password salate e hash.

  • Eseguiamo PHP 5.3 in produzione. Ciò significa che probabilmente non possiamo usare librerie che dicono che richiedono PHP 5.4+. (Dico "probabilmente" perché la nostra integrazione con CentOS include alcune funzionalità di PHP 5.4. Stiamo studiando la compatibilità di varie librerie.)

  • Al momento non disponiamo di libsodium.

  • Abbiamo entrambe le estensioni PHP mcrypt e openssl installate e abilitate.

  • Ho letto tutti i post sul blog di Scott su Paragonie. Il più rilevante è Come generare in modo sicuro stringhe e interi casuali in PHP .

Credo che la mia migliore opzione per creare una password salt in queste circostanze sia usare mcrypt per ottenere i byte da / dev / urandom:

$salt = mcrypt_create_iv(16, MCRYPT_DEV_URANDOM)

supponendo che 16 byte siano appropriati per il sale. La documentazione di PHP non dice nemmeno se quel primo parametro è in byte! Ma sembra essere così.

Abbiamo poche decine di milioni di utenti, quindi consentire 100 milioni di sali dovrebbe essere ragionevole.

Dati i miei limiti, qualcuno può suggerire un approccio migliore rispetto a prendere 16 byte casuali da / dev / urandom tramite l'estensione mcrypt?

Per essere sicuri, stiamo anche lavorando ad altri aggiornamenti per ottenere una migliore disponibilità delle biblioteche, hashing più strong, ecc. Questo è al di fuori dello scopo di questa domanda.

    
posta Edward Barnard 18.09.2015 - 00:49
fonte

1 risposta

2

Quindi cosa vuoi dai tuoi sali?

  1. Dovrebbero essere alquanto imprevedibili per prevenire attacchi pre-calcolo.
  2. Dovrebbero essere unici a livello mondiale.
  3. Dovrebbero essere il più piccoli possibile in quanto devono essere scalati in modo elevato.

L'unica supposizione che devi fare è che /dev/urandom sia sicuro e fornisca almeno numeri statisticamente casuali (che dovrebbe). Questa è un'ipotesi ragionevole in quanto altrimenti quasi tutto (criptato) sul tuo sistema sarebbe rotto, dato che molti di loro usano /dev/urandom . È inoltre necessario presupporre che mcrypt basti solo l'output di /dev/urandom .

Per soddisfare la proprietà # 1 avresti bisogno di avere almeno 128 bit (= 16 byte) di sali, ma questo ti lascerebbe con una buona probabilità di collisione dopo aver osservato 2^(128/2)=2^64 di sali, che potrebbe essere troppo presto per essere davvero sicuro di essere unico. Propongo quindi di usare i sali da 32 byte (= 256 bit) che hanno una resistenza di collisione a 128 bit rendendo davvero improbabile che mai riutilizzi sale e sale saranno ancora ragionevolmente piccoli (potreste usa anche sali di 512 bit ...).

Per quanto riguarda l'hashing della password potresti voler dare un'occhiata alla competizione relativa .

    
risposta data 18.09.2015 - 21:05
fonte

Leggi altre domande sui tag