it-swarm.it

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

Possibile duplicato:
Quale metodo di hashing della password devo usare?

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

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

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

  1. Solo per citare: non si dovrebbero mai archiviare password di testo semplice :)
  2. Hai password di hash "a senso unico", così nessuno potrà mai vedere il testo in chiaro. Quando l'utente immette la password, l'hash nello stesso modo e la confronta con il passaggio hash nel database.
  3. Oltre all'hash una password, dovresti salarla. Aggiungete il salt alla semplice stringa della password e cancellate la nuova stringa. Se la password semplice è debole, l'aggiunta del sale lo rende più lungo e più forte.
  4. Il sale dovrebbe inoltre essere casuale (ho letto che il termine "sale" significa che è casuale in ogni caso, altrimenti è stato chiamato "chiave"?). Questo per prevenire gli attacchi da tavolo arcobaleno, perché l'attaccante 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 usi sali casuali.
  5. Il sale non è un segreto! Viene archiviato nel database accanto alla password con hash. Tuttavia, potrebbe non essere la migliore idea utilizzare un timestamp, l'indirizzo e-mail dell'utente o qualsiasi altra cosa connessa all'utente come salt casuale. Come motivo è ad es. ha affermato che gli utenti tendono a utilizzare le stesse password su più siti/servizi. Quindi, il sale dovrebbe essere una stringa casuale, ho letto che sarebbe 64-bit?
  6. Il passaggio successivo consiste nell'aggiungere iterazione al processo di hashing (1000 o più loop), quindi il sale viene aggiunto alla password e vengono quindi ripetutamente sottoposti a hash, il che significa solo una frazione di secondo che l'utente deve attendere durante la registrazione in, ma riassume se hai circa 10.000 voci nel tuo DB.
  7. Potrebbe essere un leggero vantaggio se aggiungi una chiave del sito, memorizzata ad es. come var globale oltre al sale. Tuttavia, dovresti sempre supporre che anche gli aggressori abbiano accesso al tuo file system.
  8. Algoritmi di hash: ho scoperto per certo 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ì: ( http://rdist.root.org/2009/10/29/stop-using-unsafe-keyed-hashes-use-hmac/ ) alcuni dicono che l'uso delle 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 di non inventare il proprio algo, quindi ho un po 'paura solo di usare qualcosa di auto-inventato.

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

AGGIORNAMENTO: Grazie per l'ottimo feedback. C'è un punto principale mancante, come vedo e molti di voi hanno detto: la sicurezza della password, il che significa che una password sicura è la base. Penso di aver ricevuto il messaggio, grazie ancora! :)

AGGIORNAMENTO 2: Solo per completamento, ho trovato il seguente codice su http://www.lateralcode.com/creating-a-random-string-with-php/ che utilizzo 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);
47
Chris

Informazioni generali:

Bella domanda, ma tutto quello che posso dire è che dipende totalmente dall'uso. Se lo usi solo per un piccolo sito web, c'è un'alta probabilità che solo "script kiddies" ti visitino, in quel caso un semplice SHA1 con sale è anche abbastanza oggi. In questo caso, 5-8-10 anni o forse anche di più è del tutto buono, i kiddie della sceneggiatura non vi entreranno davvero se vedono che non possono entrare facilmente. Se il tuo sito verrà attaccato per qualche motivo - sito monetario, ecc., Allora dovresti usare le ultime funzioni disponibili. In questo caso avrei persino "rischiato" di utilizzare una funzione non ufficiale ma già trasferita. In questo momento c'è una competizione SHA3, per i websties che avranno un sacco di soldi, userei uno dei 5 concorrenti di questi.

I punti che dico che sono importanti:

1. usa un sale casuale, forse anche 20 caratteri. Rendere le password molto più difficili e, anche se sono fragili, richiede troppo tempo per valerne la pena.
2. usa SHA-1, SHA-2 o WHIRLPOOL. Con buon sale, anche MD5 è OK, ma suggerisco comunque questi.
. puoi usare qualsiasi crittografia eccezionale se le password degli utenti sono banali. È necessario assicurarsi che utilizzino password lunghe, non di dizionario, con lettere maiuscole e minuscole, numeri e simboli, altrimenti è facilmente fragile con la forza bruta. Potresti considerare che potrebbero essere costretti a cambiare password ogni anno o giù di lì.

Al codice:

Ripetere più volte il ciclo potrebbe essere utile, ma non credo che sia necessario 5000. 3 per la normale sicurezza è buono, o 100, forse 1000 potrebbero funzionare, ma penso che 5000 sia troppo. SHA-256 è buono, ma potresti usare un algoritmo sviluppato appositamente per questo, vedi i commenti.

2
axiomer

Hai dimenticato solo una piccola cosa:

Sicurezza della password.

Solo 2 parole che sovrappesano il tuo brillante argomento.

Ci sono davvero centinaia di argomenti su Stackoverflow che ti dicono di usare questo o quell'algoritmo di hashing e sali casuali.
E solo pochissimi spiegano che con una password debole tutta la protezione della tua lista di otto voci, tutti gli hash hmac-chmak-bumblemak extra sicuri con 2048 byte-long-salt verranno rotti in pochi secondi.

Per quanto riguarda i poveri utenti che non ricordano $#%H4df84a$%#R password: basta farle usare non una password ma una passphrase.

Is it a good day today, Winkie? Utilizza lettere maiuscole diverse e password di complessità consigliata ma molto più facili da ricordare.

Naturalmente la frase non dovrebbe essere così comune come le password comuni come "Joe" o "123".
"Buongiorno", "Oh mio Dio! Hanno ucciso Kenny!" le frasi dovrebbero essere evitate.
Ma aggiungendo un po 'di personalità andrebbe bene:
Oh My God! They moved Cthulhu! sembra abbastanza

Un'altra cosa da menzionare è una comunicazione sicura tra server e browser
Senza di essa, una semplice password può essere facilmente "sniffata" su uno qualsiasi dei router coinvolti nella comunicazione.

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

10

Una funzione di hash per scopi generici (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 siano esposte ad attacchi di forza bruta nel prossimo futuro. Il problema è che le funzioni di hash possono essere calcolate troppo rapidamente. La soluzione migliore è utilizzare bcrypt o PBKDF2 con un numero elevato di iterazioni. Bcrypt vs PBKDF2 è stato discusso su http://security.stackexchange.com .

Alcune persone potrebbero pensare che questo sia eccessivo per la maggior parte dei siti, ma ricordano che le password vengono riutilizzate continuamente e che l'archiviazione delle password è in genere qualcosa che non cambierà fino a quando non si verifica un problema.

Raccomandazioni:

  1. Usa bcrypt o PBKDF2. NON UTILIZZARE i candidati SHA3. Potrebbero contenere falle di sicurezza che non sono state ancora scoperte.
  2. Usa un sale a caso per proteggere dagli attacchi dei tavoli Rainbow.
  3. Forza gli utenti a selezionare una passphrase.

lteriori informazioni

5
tony

La funzione hash_hmac() sarebbe una buona scelta, può persino superare i problemi di un algoritmo di hash più debole. L'unico problema è che è troppo veloce. Ciò significa che con abbastanza CPU-Power (cloud), diventa possibile la creazione di diverse tabelle Rainbow, questa è la ragione per iterare. Se è necessaria questa elevata sicurezza, è possibile misurare il tempo necessario per le iterazioni e quindi calcolare il numero di iterazioni necessarie per un determinato tempo.

Modificare:

L'iterazione può risolvere questo problema, in un certo senso dovrebbe essere possibile aumentare in seguito il numero di iterazioni, senza invalidare gli hash esistenti. Ciò è 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. , ho provato a commentarlo, quindi si può capire cosa sta succedendo.

2
martinstoeckli