online - php sha password




Sicuro hash e sale per le password di PHP (10)

DISCLAIMER : questa risposta è stata scritta nel 2008.

Da allora, PHP ci ha fornito php.net/manual/en/function.password-hash.php e password_verify e, dal momento della loro introduzione, sono il metodo consigliato per l'hashing e il controllo delle password.

La teoria della risposta è comunque una buona lettura.

TL; DR

cosa non fare

  • Non limitare i caratteri che gli utenti possono immettere per le password. Solo gli idioti fanno questo.
  • Non limitare la lunghezza di una password. Se i tuoi utenti vogliono una frase con supercalifragilisticexpialidocious in essa, non impedirgli di usarla.
  • Non memorizzare mai la password dell'utente in testo normale.
  • Non inviare mai una password al tuo utente, tranne quando hanno perso la loro e ne hai inviato una temporanea.
  • Mai, mai registrare le password in alcun modo.
  • Mai parole d'ordine hash con SHA1 o MD5 o persino SHA256! I cracker moderni possono superare i 60 e 180 miliardi di hash / secondo (rispettivamente).
  • Non mischiare bcrypt e con l'output raw di hash () , usa l'output hex o base64_encode. (Questo vale per qualsiasi input che può avere un ladro \0 in esso, che può seriamente indebolire la sicurezza.)

dos

  • Usa scrypt quando puoi; bcrypt se non puoi.
  • Usa PBKDF2 se non puoi usare bcrypt o scrypt, con gli hash SHA2.
  • Ripristina le password di tutti quando il database è compromesso.
  • Implementare una lunghezza minima ragionevole di 8-10 caratteri, oltre a richiedere almeno 1 lettera maiuscola, 1 lettera minuscola, un numero e un simbolo. Ciò migliorerà l'entropia della password, rendendola più difficile da decifrare. (Vedere la sezione "Che cosa rende una buona password?" Per qualche discussione.)

Perché le password hash comunque?

L'obiettivo delle password di hashing è semplice: impedire l'accesso malevolo agli account utente compromettendo il database. Quindi l'obiettivo dell'hash delle password è quello di scoraggiare un hacker o un cracker costando loro troppo tempo o denaro per calcolare le password in testo semplice. E tempo / costo sono i migliori deterrenti nel tuo arsenale.

Un altro motivo per cui si desidera un buon hash robusto su un account utente è quello di darti il ​​tempo sufficiente per cambiare tutte le password nel sistema. Se il tuo database è compromesso, avrai bisogno di tempo sufficiente per bloccare almeno il sistema, se non cambierai ogni password nel database.

Jeremiah Grossman, CTO di Whitehat Security, ha dichiarato sul suo blog dopo un recente recupero della password che ha richiesto la violazione della sua protezione con password brute-force:

È interessante notare che, vivendo questo incubo, ho imparato MOLTO che non sapevo di password cracking, archiviazione e complessità. Sono giunto ad apprezzare il motivo per cui la memorizzazione delle password è sempre più importante della complessità della password. Se non sai come viene archiviata la tua password, tutto ciò che puoi davvero dipendere è la complessità. Questo potrebbe essere una conoscenza comune per i professionisti di password e crittografia, ma per l'esperto medio di InfoSec o Web Security, ne dubito fortemente.

(Enfasi mia.)

Ciò che rende comunque una buona password?

Entropy . (Non che io sottoscrivo pienamente il punto di vista di Randall).

In breve, l'entropia è la quantità di variazione all'interno della password. Quando una password è solo lettere minuscole in caratteri latini, è solo 26 caratteri. Questa non è una grande variazione. Le password alfanumeriche sono migliori, con 36 caratteri. Ma consentire maiuscole e minuscole, con simboli, è di circa 96 caratteri. È molto meglio delle semplici lettere. Un problema è che, per rendere memorabili le nostre password, inseriamo schemi che riducono l'entropia. Oops!

L'entropia della password è facilmente approximated . L'utilizzo dell'intera gamma di caratteri ascii (circa 96 caratteri tipizzabili) produce un'entropia di 6,6 per carattere, che a 8 caratteri per una password è ancora troppo bassa (52,679 bit di entropia) per la sicurezza futura. Ma la buona notizia è che password più lunghe e password con caratteri unicode aumentano davvero l'entropia di una password e rendono più difficile il crack.

C'è una discussione più lunga sull'entropia della password sul sito Crypto StackExchange . Una buona ricerca su Google mostrerà anche molti risultati.

Nei commenti ho parlato con @popnoodles, che ha sottolineato che l' applicazione di una password di X con X molte lettere, numeri, simboli, ecc, può effettivamente ridurre l'entropia rendendo lo schema delle password più prevedibile. Sono daccordo. La casualità, nel modo più casuale possibile, è sempre la soluzione più sicura, ma meno memorabile.

Per quanto ne so, la migliore password del mondo è Catch-22. O il suo non memorabile, troppo prevedibile, troppo breve, troppi caratteri unicode (difficile da scrivere su un dispositivo Windows / Mobile), troppo lungo, ecc. Nessuna password è veramente sufficiente per i nostri scopi, quindi dobbiamo proteggerli come se fossero erano a Fort Knox.

Migliori pratiche

Bcrypt e scrypt sono le migliori pratiche attuali. scrypt sarà migliore di bcrypt in tempo, ma non ha visto l'adozione come standard da parte di Linux / Unix o dai server web e non ha ancora avuto recensioni approfondite dell'algoritmo pubblicato. Ma ancora, il futuro dell'algoritmo sembra promettente. Se stai lavorando con Ruby, c'è una gemma che ti aiuterà e Node.js ora ha il suo pacchetto scrypt . È possibile utilizzare Scrypt in PHP tramite l'estensione Scrypt o l'estensione Libsodium (entrambi sono disponibili in PECL).

Consiglio vivamente di leggere la documentazione per la funzione crypt se vuoi capire come usare bcrypt, o openwall.com/phpass un good wrapper o usare qualcosa come openwall.com/phpass per openwall.com/phpass più legacy. Raccomando un minimo di 12 round di bcrypt, se non da 15 a 18.

Ho cambiato idea sull'uso di bcrypt quando ho appreso che bcrypt utilizza solo il programma chiave di blowfish, con un meccanismo a costo variabile. Quest'ultimo consente di aumentare il costo per forzare una password aumentando la programmazione delle chiavi già costose di blowfish.

Pratiche medie

Non riesco quasi più a immaginare questa situazione. openwall.com/phpass supporta PHP da 3.0.18 a 5.3, quindi è utilizzabile su quasi tutte le installazioni immaginabili e dovrebbe essere usato se non si è certi che il proprio ambiente supporti bcrypt.

Supponiamo però che non sia possibile utilizzare bcrypt o PHPASS. Cosa poi?

Prova un'implementazione di PDKBF2 con il numero massimo di round che il tuo ambiente / applicazione / percezione dell'utente può tollerare. Il numero più basso che raccomanderei è di 2500 colpi. Inoltre, assicurati di usare hash_hmac() se è disponibile per rendere l'operazione più difficile da riprodurre.

Pratiche future

Venire in PHP 5.5 è una libreria completa di protezione con password che astrae qualsiasi difficoltà a lavorare con bcrypt. Mentre molti di noi sono bloccati con PHP 5.2 e 5.3 negli ambienti più comuni, in particolare gli host condivisi, @ircmaxell ha creato un livello di compatibilità per la prossima API compatibile con le versioni precedenti di PHP 5.3.7.

Ricapitolazione e disclaimer della crittografia

La potenza computazionale necessaria per rompere effettivamente una password con hash non esiste. L'unico modo per i computer di "crackare" una password è di ricrearlo e simulare l'algoritmo di hash utilizzato per proteggerlo. La velocità dell'hash è correlata linearmente alla sua capacità di essere forzata bruta. Peggio ancora, la maggior parte degli algoritmi di hash può essere facilmente parallelizzata per eseguire ancora più velocemente. Questo è il motivo per cui costosi schemi come bcrypt e scrypt sono così importanti.

Non è possibile prevedere tutte le minacce o le vie di attacco, quindi è necessario fare il possibile per proteggere i propri utenti. Se non lo fai, potresti anche perdere il fatto che sei stato attaccato fino a quando non è troppo tardi ... e sei responsabile . Per evitare quella situazione, agisci paranoico per cominciare. Attaccare il proprio software (internamente) e tentare di rubare le credenziali dell'utente, modificare gli account di altri utenti o accedere ai propri dati. Se non collaudi la sicurezza del tuo sistema, allora non puoi incolpare nessuno tranne te stesso.

Infine: non sono un crittografo. Qualunque cosa abbia detto è la mia opinione, ma penso che sia basata sul buon vecchio buon senso ... e su molte letture. Ricorda, essere il più paranoico possibile, rendere le cose difficili da intromettere il più possibile, e poi, se sei ancora preoccupato, contatta un hacker o un crittografo con cappello bianco per vedere cosa dicono del tuo codice / sistema.

Attualmente è stato detto che MD5 è parzialmente insicuro. Tenendo conto di ciò, mi piacerebbe sapere quale meccanismo utilizzare per la protezione con password.

Questa domanda è "double hashing" una password meno sicura rispetto alla semplice hashing di una volta? suggerisce che l'hashing di più volte può essere una buona idea, considerando come implementare la protezione con password per i singoli file? suggerisce di usare il sale.

Sto usando PHP. Voglio un sistema sicuro e veloce di crittografia delle password. Macinare una password un milione di volte può essere più sicuro, ma anche più lento. Come raggiungere un buon equilibrio tra velocità e sicurezza? Inoltre, preferirei che il risultato avesse un numero costante di caratteri.

  1. Il meccanismo di hashing deve essere disponibile in PHP
  2. Deve essere al sicuro
  3. Può usare il sale (in questo caso, tutti i sali sono ugualmente buoni? C'è un modo per generare dei buoni sali?)

Inoltre, dovrei memorizzare due campi nel database (uno usa MD5 e un altro usando SHA, per esempio)? Lo renderebbe più sicuro o meno sicuro?

Nel caso in cui non fossi abbastanza chiaro, vorrei sapere quali funzioni di hashing usare e come scegliere un buon sale per avere un meccanismo di protezione della password sicuro e veloce.

Domande correlate che non coprono la mia domanda:

Qual è la differenza tra SHA e MD5 in PHP
Crittografia semplice password
Metodi sicuri di memorizzazione delle chiavi, password per asp.net
Come implementeresti le password salate in Tomcat 5.5


A partire da PHP 5.5, PHP ha funzioni semplici e sicure per l'hashing e la verifica delle password, php.net/manual/en/function.password-hash.php e password_verify

$password = 'anna';
$hash = password_hash($password, PASSWORD_DEFAULT);
$expensiveHash = password_hash($password, PASSWORD_DEFAULT, array('cost' => 20));

password_verify('anna', $hash); //Returns true
password_verify('anna', $expensiveHash); //Also returns true
password_verify('elsa', $hash); //Returns false

Quando viene usato password_hash() , genera un salt casuale e lo include nell'hash outputtato (insieme al costo e all'algoritmo utilizzato). password_verify() legge quindi l'hash e determina il metodo salt e di crittografia utilizzato, e lo verifica contro la password in chiaro in dotazione.

Fornendo PASSWORD_DEFAULT richiede a PHP di utilizzare l'algoritmo di hashing predefinito della versione di PHP installata. Esattamente quale algoritmo significa che è destinato a cambiare nel tempo nelle versioni future, in modo che sia sempre uno degli algoritmi disponibili più forti.

L'aumento dei costi (che ha un valore predefinito di 10) rende l'hash più difficile da applicare alla forza bruta, ma significa anche generare hash e verificare le password contro di loro sarà più utile per la CPU del tuo server.

Nota che anche se l'algoritmo di hashing predefinito può cambiare, gli hash precedenti continueranno a essere verificati correttamente perché l'algoritmo utilizzato è archiviato nell'hash e password_verify() preleva su di esso.


Google dice che SHA256 è disponibile per PHP.

Dovresti assolutamente usare un sale. Mi consiglia di utilizzare byte casuali (e non limitarti a caratteri e numeri). Come di solito, più a lungo si sceglie, più sicuro, più lento diventa. 64 byte dovrebbero andare bene, credo.


Ho trovato l'argomento perfetto su questo argomento qui: https://crackstation.net/hashing-security.htm , volevo che tu ne traggessi beneficio, qui c'è anche il codice sorgente che previene anche attacchi contro il tempo.

<?php
/*
 * Password hashing with PBKDF2.
 * Author: havoc AT defuse.ca
 * www: https://defuse.ca/php-pbkdf2.htm
 */

// These constants may be changed without breaking existing hashes.
define("PBKDF2_HASH_ALGORITHM", "sha256");
define("PBKDF2_ITERATIONS", 1000);
define("PBKDF2_SALT_BYTES", 24);
define("PBKDF2_HASH_BYTES", 24);

define("HASH_SECTIONS", 4);
define("HASH_ALGORITHM_INDEX", 0);
define("HASH_ITERATION_INDEX", 1);
define("HASH_SALT_INDEX", 2);
define("HASH_PBKDF2_INDEX", 3);

function create_hash($password)
{
    // format: algorithm:iterations:salt:hash
    $salt = base64_encode(mcrypt_create_iv(PBKDF2_SALT_BYTES, MCRYPT_DEV_URANDOM));
    return PBKDF2_HASH_ALGORITHM . ":" . PBKDF2_ITERATIONS . ":" .  $salt . ":" . 
        base64_encode(pbkdf2(
            PBKDF2_HASH_ALGORITHM,
            $password,
            $salt,
            PBKDF2_ITERATIONS,
            PBKDF2_HASH_BYTES,
            true
        ));
}

function validate_password($password, $good_hash)
{
    $params = explode(":", $good_hash);
    if(count($params) < HASH_SECTIONS)
       return false; 
    $pbkdf2 = base64_decode($params[HASH_PBKDF2_INDEX]);
    return slow_equals(
        $pbkdf2,
        pbkdf2(
            $params[HASH_ALGORITHM_INDEX],
            $password,
            $params[HASH_SALT_INDEX],
            (int)$params[HASH_ITERATION_INDEX],
            strlen($pbkdf2),
            true
        )
    );
}

// Compares two strings $a and $b in length-constant time.
function slow_equals($a, $b)
{
    $diff = strlen($a) ^ strlen($b);
    for($i = 0; $i < strlen($a) && $i < strlen($b); $i++)
    {
        $diff |= ord($a[$i]) ^ ord($b[$i]);
    }
    return $diff === 0; 
}

/*
 * PBKDF2 key derivation function as defined by RSA's PKCS #5: https://www.ietf.org/rfc/rfc2898.txt
 * $algorithm - The hash algorithm to use. Recommended: SHA256
 * $password - The password.
 * $salt - A salt that is unique to the password.
 * $count - Iteration count. Higher is better, but slower. Recommended: At least 1000.
 * $key_length - The length of the derived key in bytes.
 * $raw_output - If true, the key is returned in raw binary format. Hex encoded otherwise.
 * Returns: A $key_length-byte key derived from the password and salt.
 *
 * Test vectors can be found here: https://www.ietf.org/rfc/rfc6070.txt
 *
 * This implementation of PBKDF2 was originally created by https://defuse.ca
 * With improvements by http://www.variations-of-shadow.com
 */
function pbkdf2($algorithm, $password, $salt, $count, $key_length, $raw_output = false)
{
    $algorithm = strtolower($algorithm);
    if(!in_array($algorithm, hash_algos(), true))
        die('PBKDF2 ERROR: Invalid hash algorithm.');
    if($count <= 0 || $key_length <= 0)
        die('PBKDF2 ERROR: Invalid parameters.');

    $hash_length = strlen(hash($algorithm, "", true));
    $block_count = ceil($key_length / $hash_length);

    $output = "";
    for($i = 1; $i <= $block_count; $i++) {
        // $i encoded as 4 bytes, big endian.
        $last = $salt . pack("N", $i);
        // first iteration
        $last = $xorsum = hash_hmac($algorithm, $last, $password, true);
        // perform the other $count - 1 iterations
        for ($j = 1; $j < $count; $j++) {
            $xorsum ^= ($last = hash_hmac($algorithm, $last, $password, true));
        }
        $output .= $xorsum;
    }

    if($raw_output)
        return substr($output, 0, $key_length);
    else
        return bin2hex(substr($output, 0, $key_length));
}
?>

Sto usando openwall.com/phpass che è una semplice classe PHP con un solo file che potrebbe essere implementata molto facilmente in quasi tutti i progetti PHP. Vedi anche The H.

Per impostazione predefinita utilizzava la più potente crittografia disponibile implementata in Phpass, che è bcrypt e ricade su altre crittografie fino a MD5 per fornire compatibilità con le versioni precedenti di framework come Wordpress.

L'hash restituito potrebbe essere memorizzato nel database così com'è. L'esempio di utilizzo per la generazione di hash è:

$t_hasher = new PasswordHash(8, FALSE);
$hash = $t_hasher->HashPassword($password);

Per verificare la password, si può usare:

$t_hasher = new PasswordHash(8, FALSE);
$check = $t_hasher->CheckPassword($password, $hash);

Una risposta molto più breve e più sicura : non scrivere affatto il proprio meccanismo di password , utilizzare un meccanismo collaudato.

La maggior parte dei programmatori semplicemente non ha le competenze per scrivere codice relativo alla crittografia senza introdurre vulnerabilità.

Autotest rapido: cos'è lo stretching della password e quante iterazioni dovresti usare? Se non conosci la risposta, dovresti usare password_hash() , poiché l'estensione della password è ora una caratteristica critica dei meccanismi delle password dovuta a CPU molto più veloci e all'uso di GPU e FPGA per decifrare le password a un tasso di miliardi di ipotesi al secondo (con GPU).

Ad esempio, è possibile decifrare tutte le password di Windows a 8 caratteri in 6 ore utilizzando 25 GPU installate in 5 PC desktop. Questo è brute-forcing cioè enumerare e controllare ogni password di Windows di 8 caratteri , inclusi caratteri speciali, e non è un attacco di dizionario. Era il 2012, dal 2018 potresti utilizzare un minor numero di GPU o craccare più velocemente con 25 GPU.

Ci sono anche molti attacchi di rainbow table su password di Windows che girano su CPU ordinarie e sono molto veloci. Tutto ciò è dovuto al fatto che Windows non salta o non allunga le sue password, anche in Windows 10 - non commettere lo stesso errore di Microsoft!

Guarda anche:

  • risposta eccellente con ulteriori informazioni sul perché password_hash() o phpass sono il modo migliore per andare.
  • buon articolo del blog che fornisce "fattori di lavoro" raccomandati (numero di iterazioni) per i principali algoritmi inclusi bcrypt, scrypt e PBKDF2.

SHA1 e un sale dovrebbero essere sufficienti (a seconda, naturalmente, se si sta codificando qualcosa per Fort Knox o un sistema di login per la tua lista della spesa) per il prossimo futuro. Se SHA1 non è abbastanza buono per te, usa SHA256 .

L'idea di un sale è di sbilanciare i risultati dell'asportazione, per così dire. Ad esempio, è noto che l'hash MD5 di una stringa vuota è d41d8cd98f00b204e9800998ecf8427e. Quindi, se qualcuno con una memoria abbastanza buona vedrebbe quell'hash e sa che è l'hash di una stringa vuota. Ma se la stringa è salata (ad esempio, con la stringa " MY_PERSONAL_SALT"), l'hash per la 'stringa vuota' (cioè " MY_PERSONAL_SALT") diventa aeac2612626724592271634fb14d3ea6, quindi non ovvio per il backtrace. Quello che sto cercando di dire è che è meglio usare qualsiasi sale, piuttosto che non farlo. Pertanto, non è troppo importante sapere quale sale usare.

In realtà ci sono siti web che fanno proprio questo : puoi nutrirlo con un hash (md5), e sputa un testo in chiaro noto che genera quel particolare hash. Se si dovesse accedere a un database che memorizza gli hash md5, sarebbe banale inserire l'hash per l'amministratore in tale servizio ed effettuare il login. Tuttavia, se le password fossero state salate, tale servizio sarebbe diventato inefficace.

Inoltre, il double-hashing è generalmente considerato come metodo cattivo, perché diminuisce lo spazio dei risultati. Tutti gli hash popolari sono a lunghezza fissa. Quindi, puoi avere solo un valore finito di questa lunghezza fissa, ei risultati diventano meno vari. Questo potrebbe essere considerato come un'altra forma di salatura, ma non lo consiglierei.


COSE DA RICORDARE

Molto è stato detto sulla crittografia della password per PHP, la maggior parte dei quali è un ottimo consiglio, ma prima ancora di iniziare il processo di utilizzo di PHP per la crittografia della password assicurati di avere implementato o pronto per essere implementato.

SERVER

PORTS

Non importa quanto sia buona la crittografia se non si protegge adeguatamente il server che esegue PHP e DB, tutti i vostri sforzi sono inutili. La maggior parte dei server funziona in modo simile, hanno porte assegnate per permetterti di accedervi da remoto tramite ftp o shell. Assicurati di cambiare la porta predefinita di cui hai mai attivato la connessione remota. In caso contrario, in effetti l'utente malintenzionato ha fatto un passo in meno nell'accedere al sistema.

NOME UTENTE

Per tutto ciò che è buono al mondo non utilizzare il nome utente admin, root o qualcosa di simile. Inoltre, se si è su un sistema basato su UNIX, NON rendere accessibile l'accesso all'account root, dovrebbe sempre essere solo sudo.

PAROLA D'ORDINE

Dì ai tuoi utenti di fare delle buone password per evitare di essere violati, fare lo stesso. Qual è il punto in cui passa tutto lo sforzo di bloccare la porta principale quando hai la backdoor spalancata.

BANCA DATI

SERVER

Idealmente si desidera il DB e l'APPLICAZIONE su server separati. Ciò non è sempre possibile a causa dei costi, ma consente una certa sicurezza in quanto l'utente malintenzionato dovrà eseguire due passaggi per accedere completamente al sistema.

UTENTE

Fai in modo che l'applicazione disponga di un proprio account per accedere al DB e fornisca solo i privilegi necessari.

Quindi avere un account utente separato per te che non è memorizzato da nessuna parte sul server, nemmeno nell'applicazione.

Come sempre NON fare questa radice o qualcosa di simile.

PAROLA D'ORDINE

Seguire le stesse linee guida di tutte le password valide. Inoltre, non riutilizzare la stessa password su qualsiasi account SERVER o DB sullo stesso sistema.

PHP

PAROLA D'ORDINE

MAI MAI memorizzare una password nel DB, invece memorizzare l'hash e il sale unico, spiegherò perché dopo.

hashing

ONE WAY HASHING !!!!!!!, Mai hash una password in modo che possa essere invertita, Hash dovrebbe essere unidirezionale, nel senso che non li si inverte e li si confronta con la password, invece si hash la password inserita allo stesso modo e confrontare i due hash. Ciò significa che anche se un utente malintenzionato accede al DB, non sa quale sia la vera password, ma solo il suo hash risultante. Il che significa maggiore sicurezza per i tuoi utenti nel peggiore scenario possibile.

Esistono molte buone funzioni di hashing ( password_hash , hash , ecc ...) ma è necessario selezionare un buon algoritmo affinché l'hash sia efficace. (bcrypt e quelli simili ad esso sono algoritmi decenti).

Quando la velocità di hashing è la chiave, tanto più lento è il più resistente agli attacchi di forza bruta.

Uno degli errori più comuni nell'hashing è che gli hash non sono unici per gli utenti. Ciò è principalmente dovuto al fatto che i sali non sono generati in modo univoco.

SALATURA

Le password devono essere sempre salate prima dell'hash. Salting aggiunge una stringa casuale alla password in modo che password simili non appaiano uguali nel DB. Tuttavia, se il sale non è univoco per ogni utente (ad esempio: si utilizza un sale codificato duro) di quanto tu abbia praticamente reso il tuo sale senza valore. Perché una volta che un utente malintenzionato calcola una password, ha il sale per tutti loro.

Quando crei un sale, assicurati che sia univoco per la password che sta salendo, quindi memorizza sia l'hash completato che il sale nel tuo DB. Ciò che questo farà sarà fare in modo che un attaccante debba crackare singolarmente ogni sale e hash prima che possano accedervi. Questo significa molto più lavoro e tempo per l'attaccante.

UTENTI CHE CREANO PASSWORD

Se l'utente sta creando una password attraverso il frontend significa che deve essere inviata al server. Questo apre un problema di sicurezza perché ciò significa che la password non crittografata viene inviata al server e se un utente malintenzionato è in grado di ascoltare e accedere al fatto che tutta la sicurezza in PHP non ha alcun valore. Trasmetti SEMPRE i dati in modo SICURO, questo viene fatto tramite SSL, ma sii stanco anche se SSL non è perfetto (il difetto di Heartbleed di OpenSSL ne è un esempio).

Inoltre, fai in modo che l'utente crei una password sicura, è semplice e dovrebbe sempre essere fatto, l'utente sarà grato per questo alla fine.

Infine, a prescindere dalle misure di sicurezza adottate, niente è sicuro al 100%, più avanzata sarà la tecnologia da proteggere, più gli attacchi diventeranno avanzati. Ma seguire questi passaggi renderà il tuo sito più sicuro e molto meno desiderabile da attaccare.

Ecco una classe PHP che crea un hash e sale per una password facilmente

http://git.io/mSJqpw


ok nel modo in cui abbiamo bisogno di sale deve essere unico quindi lasciatelo generare

   /**
     * Generating string
     * @param $size
     * @return string
     */
    function Uniwur_string($size){
        $text = md5(uniqid(rand(), TRUE));
        RETURN substr($text, 0, $size);
    }

inoltre abbiamo bisogno dell'hash che sto usando sha512 è il migliore ed è in php

   /**
     * Hashing string
     * @param $string
     * @return string
     */
    function hash($string){
        return hash('sha512', $string);
    }

quindi ora possiamo usare queste funzioni per generare password sicure

// generating unique password
$password = Uniwur_string(20); // or you can add manual password
// generating 32 character salt
$salt = Uniwur_string(32);
// now we can manipulate this informations

// hashin salt for safe
$hash_salt = hash($salt);
// hashing password
$hash_psw = hash($password.$hash_salt);

ora abbiamo bisogno di salvare nel database il nostro valore variabile $ hash_psw e variabile $ salt

e per autorizzare useremo gli stessi passi ...

è il modo migliore per proteggere le password dei nostri clienti ...

Ps per gli ultimi 2 passaggi puoi usare il tuo algoritmo ... ma assicurati di poter generare questa password hash in futuro quando devi autorizzare l'utente ...


Alla fine, il doppio hashing, matematicamente, non fornisce alcun vantaggio. In pratica, tuttavia, è utile per prevenire attacchi basati su tabelle arcobaleno. In altre parole, non è più vantaggioso dell'hash con un salt, che richiede molto meno tempo del processore nell'applicazione o sul server.





protection