Password hashing e blowfish [duplicato]

-2

Quello che sto per dire probabilmente mi farà sembrare un idiota ma è meglio sbagliare e imparare che avere domande senza risposta.

Da quando ho iniziato a occuparmi di password mi sono chiesto quale sia il grosso problema delle password di hashing in ogni caso, dal momento che se qualcuno si impossessa del tuo database potrebbe scoprire qualsiasi password, indipendentemente dalla tecnica di hashing utilizzata.

Quindi fondamentalmente il grande difetto delle vecchie funzioni di hashing erano le tabelle arcobaleno, qualcosa che l'algoritmo attualmente usato da PHP nella loro password hashing API, blowfish, si occupa di. Certo, è piuttosto complesso e senza dubbio è costruito da persone molto più intelligenti di me, ma comunque non ho potuto fare a meno di chiedermi se avessi costruito la mia funzione di hashing che non era vulnerabile alle tabelle arcobaleno e non ho immagazzinato il sale in posti ovvi come colonne aggiuntive nel database o utilizzare le informazioni utente come nome o email come sale, sarebbe utile?

Ho appena trascorso 5 minuti per preparare questo esempio per te, che utilizza, naturalmente, md5, come so che è il più odiato dai critici degli sviluppatori di PHP :D

function my_password_hash($password){
    $salt = substr(md5(str_shuffle('0123456789abcdef')), 0, 5);

    $hash = substr(md5($password . $salt), 0, -5) . $salt;

    return $hash;
}

function my_password_check($password, $hash){

    $salt = substr($hash, -5);

    return substr(md5($password . $salt), 0, -5) . $salt === $hash;
}

$hash = my_password_hash('qwerty');

var_dump(my_password_check('qwerty', $hash)); // TRUE
var_dump(my_password_check('qwertY', $hash)); // FALSE

Produrrà diversi hash per lo stesso input ogni volta e il sale verrà mescolato nell'hash finale dell'output, se non sai esplicitamente dove si trova, non penso che possa essere trovato, ma è per questo che I Sto scrivendo qui, per scoprire se ho torto.

    
posta php_nub_qq 21.02.2015 - 23:42
fonte

2 risposte

2

La tua prima ipotesi, che un utente malintenzionato che ha ottenuto l'accesso al database può trovare tutte le password, non è valido. Anche una singola chiamata di MD5 senza sale e senza iterazioni manterrà le password più sicure al sicuro.

Ma solo una piccolissima percentuale di utenti usa una password, che è abbastanza strong da rimanere al sicuro con un semplice hashing.

Chiamando le tabelle arcobaleno un punto debole non è esattamente corretto. Le tabelle Rainbow sono un metodo per attaccare una debolezza molto specifica in alcuni hash delle password. Ma ci sono altri modi per attaccare la stessa debolezza, anche alcuni metodi che consumano meno memoria e tempo CPU rispetto all'utilizzo di tabelle arcobaleno.

Questa debolezza è facilmente risolvibile usando un sale. Un hash salato sconfiggerà sia i tavoli arcobaleno che la maggior parte degli altri attacchi di forza bruta. Gli hash delle password all'avanguardia utilizzano sale per decenni. Persino il vecchio (e ormai obsoleto) hash della password basato su DES usato un sale.

Il tuo approccio alla salatura condivide un punto debole con i sali utilizzati nelle password basate su DES, e questa è la lunghezza del sale. Il sale dovrebbe essere abbastanza lungo da non ripetersi mai, neanche per caso se ogni sistema informatico del mondo utilizza lo stesso algoritmo di hashing della password per tutte le password memorizzate per secoli.

L'utilizzo di un sale sufficientemente lungo è praticamente gratuito, quindi non vi è alcun motivo per utilizzare un sale con solo 20 bit di entropia.

Aggiungere sale e hash è una pratica comune. A tale riguardo il tuo approccio è praticamente identico ai metodi standard. I metodi standard includono tuttavia una specifica di formato, al fine di preservare la compatibilità nel caso in cui l'algoritmo debba essere modificato. Di solito mettono anche un separatore esplicito tra sale e hash.

Lasciando fuori il separatore e fingendo che rallenterà un attaccante è la sicurezza attraverso l'oscurità. Non funziona.

L'oscurità è più probabile che confonda lo sviluppatore e causi un errore di sicurezza nel codice durante lo sviluppo, piuttosto che impedire effettivamente un attacco.

Il modo in cui generi casualità sembra strano, ma non ne so abbastanza sulla piattaforma specifica che stai sviluppando per dire se è un approccio ragionevole.

Ci sono altri aspetti relativi agli hash delle password che possono avere un impatto sulla sicurezza, ma non c'è un consenso totale su questi punti.

C'è accordo sul fatto che sia meglio usare hash più recenti senza punti deboli noti, piuttosto che usare MD5. Tuttavia, nessuno dei punti deboli noti di MD5 potrebbe effettivamente essere utilizzato per attaccare l'hashing della password nella tua domanda. Un attacco contro di esso si concentrerebbe sicuramente sulle password deboli e sul breve sale.

Poi c'è la domanda se l'hashing della password debba usare le iterazioni o fare tutti i tipi di altri costosi calcoli. Tali approcci rallenteranno gli usi legittimi e gli attacchi di forza bruta con lo stesso fattore. In quanto tali non sono molto efficaci. Aumentare la lunghezza di una password da 10 a 11 caratteri rallenterebbe solo l'utilizzo legittimo del 10%, ma potrebbe rallentare gli attacchi di forza bruta di un ordine di grandezza. Ecco perché le password più lunghe sono un modo migliore per rallentare gli attacchi.

Questo non vuol dire che gli hash iterati siano inutili, rallentano gli attacchi. Ma rallentano anche l'uso legittimo sul proprio server, il che rende un obiettivo più facile per gli attacchi DoS.

    
risposta data 22.02.2015 - 00:26
fonte
1

Se qualcuno accede al database con le password in, potrebbero avere abbastanza accesso al sistema per leggere anche il codice che implementa l'hashing. Se lo fanno, allora conoscono la struttura delle password con hash.

È anche comune che l'attaccante conosca almeno una password sul sistema (la propria), quindi se ottengono l'hash per la propria password, allora potrebbero essere in grado di elaborare la struttura confrontando la propria password e password salata.

La buona notizia è che la salatura funziona anche se l'attaccante sa come viene costruito e immagazzinato il sale. Per un costo molto basso quando si imposta & controllando le password, rendi enormemente più costoso / lento a decifrare le password in blocco. Quindi non c'è bisogno di preoccuparsi di nascondere la struttura (i file delle password shadow di Unix / Linux non lo fanno, per esempio) - piuttosto si preoccupano solo di generare sali con abbastanza entropia da rendere il lavoro dell'aggressore molto più lento.

Mentre un hash può sempre essere invertito con abbastanza tempo, l'obiettivo è solo quello di renderlo lento / costoso per l'attaccante, quindi a) l'attaccante si arrende e passa a un bersaglio più facile, b) puoi notare che tu sono stati violati e gli utenti hanno deciso di cambiare le loro password prima che molte password siano state compromesse.

Se capisco bene il tuo codice PHP, elimina parte dell'hash md5 per sostituirlo con il sale, riducendo direttamente la sicurezza del tuo hash. Scambiare la forza dell'hash per un po 'di oscurità è un compromesso, poiché la salatura funziona anche se l'aggressore sa come è fatto. Utilizzare idealmente un'implementazione esistente come crypt (), poiché la sua implementazione (almeno sui sistemi moderni) dovrebbe riflettere le migliori pratiche.

    
risposta data 22.02.2015 - 00:54
fonte

Leggi altre domande sui tag