Sicurezza delle password nei database: oggi sono ancora le migliori pratiche? [duplicare]

47

Ci sono un sacco di ottimi post sulla sicurezza delle password nei database sullo stack overflow e su altri siti e, visto che sono completamente nuovo, ho passato parecchie ore a cercare di saperne di più su di esso negli ultimi giorni. Tuttavia, ci sono così tanti suggerimenti e best practice diversi che mi sono ancora molto confuso ...

Inoltre, ci sono ancora molti post più vecchi del 2007-2010, ecc. Come ho visto quanto velocemente cambiano le cose, non sono sicuro che sia ancora usuale usarlo come suggeriscono. Quindi, volevo sintetizzare ciò che ho trovato nei post e poi chiedere se questo metodo che ho trovato fosse una buona pratica ...

Quindi, questa non è una guida, ma un riassunto, so che è molto semplice e se ci sono errori per favore correggimi!

  1. Solo per menzionare: non si dovrebbero mai memorizzare password in testo semplice:)
  2. Le password di hash "a senso unico", in modo che nessuno possa mai vedere il testo normale. Quando l'utente inserisce la password, la si agisce allo stesso modo e la si confronta con il passaggio hash nel database.
  3. Oltre all'hash una password, dovresti saltarla. Aggiungete il sale alla stringa di password semplice e cancellate la nuova stringa. Se la password semplice è debole, l'aggiunta di sale lo rende più lungo e più strong.
  4. Il sale dovrebbe inoltre essere casuale (ho letto che il termine "sale" significa che è comunque casuale, altrimenti è stato chiamato "chiave"?). Questo serve a prevenire gli attacchi della tabella arcobaleno, perché l'utente malintenzionato dovrebbe creare una tabella per ogni sale che è molto più costoso in termini di tempo ecc. Inoltre, se due utenti hanno la stessa password non la riconoscerai se utilizzi sali casuali.
  5. Il sale non è un segreto! Viene memorizzato nel database accanto alla password con hash. Tuttavia, potrebbe non essere la migliore idea usare un timestamp, l'indirizzo e-mail dell'utente o qualsiasi altra cosa collegata all'utente come un sale casuale. Come ragione, ad es. menzionato che gli utenti tendono a utilizzare le stesse password su più siti / servizi. Quindi, il sale dovrebbe essere una stringa casuale, ho letto meglio sarebbe 64-bit?
  6. Il prossimo passo consiste nell'aggiungere iterazione al processo di hashing (1000 o più cicli), quindi il sale viene aggiunto alla password e viene quindi sottoposto a hashing più e più volte, il che significa solo una frazione di secondo per l'utente attendi quando accedi, ma riassume se hai un po 'di 10.000 voci nel tuo DB.
  7. Potrebbe essere un leggero vantaggio, se aggiungi una chiave del sito, memorizzata ad es. come una varietà globale oltre al sale. Tuttavia, dovresti sempre supporre che gli hacker abbiano anche accesso al tuo file system.
  8. Algoritmi di hash: ho trovato di sicuro che non è più sicuro usare MD5, SHA1 e altri metodi deboli ...

Quindi ci sono opinioni diverse su come usare SHA256, SHA512? Dovresti usare hash_hmac? Alcuni dicono di sì: ( link ) alcuni dicono usare le librerie è l'unico modo sicuro ... e poi una o due volte in un post ho letto di non usare le librerie come bcrypt o bubble fish ??

È davvero necessario utilizzare una libreria o è ad es. un metodo come questo abbastanza:

function hash_password($password, $nonce) {

  for ($i = 0; $i < 5000; $i++) {
    $hashed_pass = hash_hmac('sha512', $hashed_pass . $nonce . $password, $site_key);
    }
  return $hashed_pass;
}

Molte persone dicono che non inventano il tuo algo, quindi sono un po 'spaventato solo per usare qualcosa che si è auto-inventato.

Posso immaginare che sia difficile da prevedere, ma per quanto tempo un metodo può essere considerato abbastanza sicuro?

AGGIORNAMENTO: Quindi, grazie per tutti i vostri ottimi feedback. Manca un punto principale, come ho visto e molti di voi hanno detto: sicurezza della password, il che significa che una password complessa è fondamentale. Penso di aver ricevuto il messaggio, grazie ancora! :)

UPDATE 2: Solo per il completamento, ho trovato il seguente codice su link che uso per generare un salt casuale:

function rand_string( $length ) {
    $chars = "abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789!§$%&/().-:;_#+*[]{}="; 

    $size = strlen( $chars );
    for( $i = 0; $i < $length; $i++ ) {
        $str .= $chars[ rand( 0, $size - 1 ) ];
    }

    return $str;
}

$random_salt= rand_string(20);
    
posta Chris 29.02.2012 - 10:25
fonte

5 risposte

2

Informazioni generali:

Bella domanda, ma tutto quello che posso dire è che dipende totalmente dall'utilizzo. Se la usi solo per un sito web di piccole dimensioni, è molto probabile che solo "script kiddies" ti visiterà, in tal caso un semplice SHA1 con sale è già abbastanza completo anche oggi. In questo caso, 5-8-10 anni o forse anche di più è totalmente buono, i kiddies di script non vi entreranno realmente se vedono che non possono intromettersi facilmente. Se il tuo sito verrà attaccato per qualche motivo - sito monetario, ecc. Allora dovresti usare le ultime funzioni disponibili. In questo caso, rischierei persino di utilizzare una funzione non ufficiale ma già trasferita. In questo momento c'è una competizione SHA3, per i siti web che hanno un sacco di soldi, userei uno dei 5 concorrenti di questi.

I punti che dico sono importanti:

1. usa un salt casuale, forse anche 20 caratteri. Rende molto più difficile rompere le password, e anche se sono irrisolvibili, ci vuole troppo tempo per valere.
2. usa SHA-1, SHA-2 o WHIRLPOOL. Con buon sale, anche MD5 è OK, ma continuo a suggerirli.
3. puoi usare qualsiasi crittografia avanzata se le password degli utenti sono banali. Devi assicurarti che usino parole non-dizionario, password lunghe con lettere maiuscole, minuscole, numeri e simboli altrimenti è facilmente infrangibile dalla forza bruta. Potresti considerare che potrebbero essere costretti a cambiare password ogni anno o giù di lì.

Al codice:

Il looping molte volte potrebbe essere utile ma non credo che sia necessario 5000. 3 per la normale sicurezza è buono, o 100, forse 1000 potrebbe funzionare, ma penso che il 5000 sia semplicemente troppo. SHA-256 è buono, ma è possibile utilizzare un algoritmo appositamente sviluppato per questo, vedere i commenti.

    
risposta data 29.02.2012 - 10:35
fonte
10

Hai dimenticato solo una piccola cosa:

Forza password.

Solo 2 parole che sovrappongono il tuo brillante argomento.

Ci sono davvero centinaia di argomenti su Stackoverflow che ti dicono di usare questo o quell'algoritmo di hashing e i sali casuali.
E solo pochissimi spiegano che con una password debole tutte le tue protezioni di otto elementi, tutti gli hash di hmac-chmak-bumblemak extra-sicuri con 2048 byte a lungo saranno interrotti in pochi secondi.

Per quanto riguarda i poveri utenti che non riescono a ricordare $#%H4df84a$%#R di password - basta far loro usare non una password ma una frase di accesso .

Is it a good day today, Winkie? Utilizza lettere maiuscole e minuscole nonché la password della complessità consigliata ma molto più facile da ricordare.

Ovviamente la frase non dovrebbe essere comune come le password comuni come "Joe" o "123".
"Buon giorno", "Oh mio Dio! Hanno ucciso Kenny!" le frasi dovrebbero essere evitate.
Ma aggiungendo qualche personalità sarebbe okay:
Oh My God! They moved Cthulhu! sembra abbastanza

Un'altra cosa da menzionare è una comunicazione sicura tra server e browser
Senza di esso, una semplice password può essere facilmente "annusata" su qualsiasi router coinvolto nella comunicazione.

SSH o un'implementazione di l'autorizzazione del digest non è meno essenziale.

    
risposta data 29.02.2012 - 11:00
fonte
5

Una funzione hash di uso generico (MD5, SHA1, SHA256) con un buon hash potrebbe essere abbastanza sicura per la maggior parte dei siti Web più piccoli, data l'attuale potenza di calcolo. Tuttavia, la legge di Moore garantirà che anche le buone password saranno esposte agli attacchi di forza bruta nel prossimo futuro. Il problema è che le funzioni di hash possono essere calcolate troppo velocemente. La soluzione migliore è utilizzare bcrypt o PBKDF2 con un numero elevato di iterazioni. Bcrypt vs PBKDF2 è stato discusso in link .

Alcune persone potrebbero pensare che questo sia eccessivo per la maggior parte dei siti, ma ricorda che le password vengono sempre riutilizzate e che l'archiviazione delle password è di solito qualcosa che non cambierà fino a quando non ci sarà un problema.

Suggerimento:

  1. Usa bcrypt o PBKDF2. NON USARE i candidati SHA3. Potrebbero contenere buchi di sicurezza che non sono stati ancora scoperti.
  2. Utilizza un sale casuale per proteggere dagli attacchi dei tavoli arcobaleno.
  3. imponi agli utenti di selezionare una passphrase.

Ulteriori informazioni

    
risposta data 29.02.2012 - 18:32
fonte
2

La funzione hash_hmac() sarebbe una buona scelta, può anche superare i problemi di un algoritmo hash più debole. L'unico problema è che è troppo veloce. Ciò significa che con sufficiente potenza di cpu (cloud), la creazione di diverse tabelle arcobaleno diventa possibile, questa è la ragione per iterare. Se hai bisogno di questa elevata sicurezza, puoi misurare il tempo di cui necessitano le iterazioni e quindi calcolare il numero di iterazioni necessarie per un dato periodo.

Modifica:

L'iterazione può risolvere questo problema, dovrebbe essere fatto in un modo, che si possa aumentare il numero di iterazioni in seguito, senza rendere invalidi gli hash esistenti. Questo è necessario per adattarsi al nuovo hardware futuro, ma richiede di memorizzare i parametri di hashing insieme all'hash.

L'algoritmo di hash bcrypt è stato progettato per soddisfare queste esigenze, ho scritto un piccolo esempio di come usare bcrypt con PHP 5.3 , ho provato a commentarlo, così si può capire cosa sta succedendo.

    
risposta data 29.02.2012 - 11:30
fonte
-1

Beh, prima di tutto, non stai inventando un tuo algoritmo. Stai utilizzando uno esistente (sha512).

In secondo luogo, fai un ciclo di 5000 volte, che non ti farà bene. Solo un paio di volte sarà sufficiente.

In terzo luogo, se stai memorizzando una password con sha512 e aggiungi un buon seed, è veramente difficile recuperare la password. E a meno che tu non sia con l'FBI o qualcosa del genere, dovrebbe essere considerato abbastanza sicuro dal momento che ci vorranno anni per decrittografare 1 password, per non parlare dell'intero database degli utenti.

    
risposta data 29.02.2012 - 10:31
fonte

Leggi altre domande sui tag