Il modo migliore per accedere alle password hash in PHP?

0

Sono passato a PHP 7.0 molto di recente e mi chiedevo se password_hash fosse meglio che crearne di propri e utilizzare la funzione crypt. Ho tre esempi di codice e non so quali rendono le password più sicure.

Esempio n. 1 (BCRYPT):

$options = [

    'cost' => 12,

];

$hashed_password = password_hash("foo", PASSWORD_BCRYPT, $options);

Esempio n. 2 (PASSWORD_DEFAULT):

$options = [

    'cost' => 12,

];

$hashed_password = password_hash("foo", PASSWORD_DEFAULT, $options);

Esempio n. 3 (FUNZIONE CRIPT):

$Blowfish_Pre = '$2y$05$';
$Blowfish_End = '$';

$Allowed_Chars = 'ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789./';

$Chars_Len = 63;

$Salt_Length = 21;

for( $i = 0; $i < $Salt_Length; $i++ )
{
$salt .= $Allowed_Chars[mt_rand(0,$Chars_Len)];
}

$bcrypt_salt = $Blowfish_Pre.$salt.$Blowfish_End;

$hashed_password = crypt($password, $bcrypt_salt);
    
posta WateR 23.07.2016 - 23:45
fonte

2 risposte

1

Nella tua alternativa crypt , costruisci il sale usando mt_rand . Questo non è raccomandato, perché la qualità crittografica (cioè non è abbastanza casuale) non è sufficiente. Questo è esplicitamente documentato:

CAUTION: This function does not generate cryptographically secure values, and should not be used for cryptographic purposes. If you need a cryptographically secure value, consider using random_int(), random_bytes(), or openssl_random_pseudo_bytes() instead.

La seconda alternativa sembra la più promettente. L'implementazione si prenderà cura della salatura sicura , come sottolineato nel manuale:

Warning: The salt option has been deprecated as of PHP 7.0.0. It is now preferred to simply use the salt that is generated by default.

e

Caution: It is strongly recommended that you do not generate your own salt for this function. It will create a secure salt automatically for you if you do not specify one.

Questo significa anche che se in questa funzione viene identificata una debolezza di soem, ne otterrai una migliore, mentre per la tua chiamata di cripta personalizzata, potresti non scoprire mai se ci sarebbe un difetto.

La prima alternativa è piacevole per la compatibilità. Ma rispetto al secondo, tronca la password dell'utente a 72 caratteri. Ok: ammetto di non usare una password così lunga, ma in alcuni ambienti, gli utenti sono istruiti a utilizzare lunghe passphrase. il parametro predefinito non ha questo vincolo ed è quindi più strong.

Nota anche che la lunghezza dell'hash è di 60 byte in questa situazione. L'algoritmo predefinito non specifica la lunghezza esatta ma può essere più lungo e potrebbe a lungo termine utilizzare hash più forti.

    
risposta data 24.07.2016 - 00:21
fonte
0

Il primo esempio va bene. Lo svantaggio è che non sarai in grado di trarre vantaggio automaticamente da un algoritmo predefinito più potente. Se mantieni il tuo codice, non dovrebbe essere un grosso problema.

Il secondo esempio ha il problema che l'interpretazione del parametro cost è stata specificata per il parametro bcrypt. I suoi successori potrebbero interpretarlo diversamente o per niente. Se utilizzi PASSWORD_DEFAULT eviterei di specificare le opzioni specifiche dell'algoritmo e di utilizzare solo i valori predefiniti.

Il terzo esempio è problematico perché usa un RNG non crittografico per generare il sale. Mentre i sali non hanno bisogno di essere segreti, questo si tradurrà in collisioni comuni a causa della semina RNG schifoso. Se hai bisogno di supportare versioni precedenti di PHP, usa ircmaxell / password_compat che utilizza crypt sotto il cofano, ma è stato accuratamente scritto da un esperto.

    
risposta data 22.09.2016 - 09:34
fonte

Leggi altre domande sui tag