Come può essere sicuro un hash che contiene un algoritmo da scegliere?

2

Stavo pensando di creare la mia funzione hash + salt, qualcosa come sha1(password + md5(login)) , poi ho letto qui (parte 4) che creare la propria funzione hash + salt è una cattiva idea, perché se l'hacker recupera il contenuto e il codice del database può capire il meccanismo dietro di esso.

Quindi ho letto il manuale PHP per password_hash() e password_verify() funzioni (è apparso con PHP 5.5), prima non capivo perché password_verify() accetti solo 2 parametri (la vera password e il suo hash), poi ho visto presente nella documentazione : l'hash contiene l'algoritmo da scegliere .

Quindi, considero che decido di archiviare questo hash generato nel mio database e un hacker che sa come password_hash() lavori trovi il mio contenuto del database, non sarebbe meno sicuro della creazione della mia hash + funzione salt? Perché dovrei usare password_hash() / password_verify() ?

    
posta Gugelhupf 28.07.2015 - 17:17
fonte

3 risposte

2

Vedi questo per un'introduzione sull'hash della password.

Che il tuo metodo ("sha1 (password + md5 (login))") possa essere indovinato dall'attentatore è non un problema . Bene, è un problema indiretto . Idealmente, un "algoritmo segreto" ti proteggerà anche se il suddetto algoritmo segreto fosse abissalmente debole, perché l'attaccante non avrebbe ancora conosciuto le estremità o le code di ciò che fai. Sfortunatamente, gli algoritmi non possono essere tenuti segreti; e, ancora più sfortunatamente, il tuo suggerimento specifico è abissalmente debole.

Ci sono due problemi principali nel tuo suggerimento:

  • Il nome di accesso è un sale negativo, perché non cambia quando l'utente cambia la sua password; e inoltre, gli stessi nomi di login possono apparire in diversi sistemi, quindi vale la pena precalcolare gli hash per l'accesso "admin".
  • Tutto è troppo veloce. Una GPU standard di base sarà in grado di provare miliardi (letteralmente) di password al secondo. Non molte password utente resistono a lungo a quella velocità.

Poi c'è il problema più concettuale che è quello di "rolling your own crypto", che è noto per essere una cattiva idea. Il problema con crypto è che non puoi testare per sicurezza: non c'è modo di accertare che ciò che hai prodotto sia sicuro o meno. I test funzionali possono dirti se il tuo sistema funziona , non se resiste agli attacchi. Per valutare la sicurezza di un algoritmo o protocollo crittografico, il modo migliore (che non è necessariamente buono, ma non abbiamo di meglio) è pubblicarlo e lasciare che decine di crittografi provino a romperlo per qualche tempo (contato in anni, perché < non puoi affrettare l'arte ). Se l'algoritmo sopravvive a 5 anni di tentativi attivi, probabilmente è buono, o almeno non banalmente debole.

    
risposta data 28.07.2015 - 20:11
fonte
0

Hai frainteso il motivo per cui non dovresti tentare di eseguire la procedura di hashing della tua password: non è che conoscere i dettagli dell'algoritmo può portare a qualcuno a capire il meccanismo dietro di esso (in realtà, è previsto: vedi il principio di Kerechoff ), è che scrivere una buona crittografia è difficile.

Ad esempio, la funzione che hai proposto è debole: non stai utilizzando random salt e non sono allunga le tue chiavi , due errori che rendono vulnerabile il tuo algoritmo agli attacchi di forza bruta da chiunque abbia accesso a il tuo database.

    
risposta data 28.07.2015 - 17:32
fonte
0

La sicurezza in una funzione hash non è che il meccanismo sia sconosciuto - è che la funzione hash è stata provata nel tempo per essere sicura. Ad esempio, distribuzione uniforme sullo spazio delle chiavi e proprietà crittografiche come resistenza di collisione, resistenza di preimage e seconda resistenza di preimage. L'hashing della password, la resistenza alle collisioni e le seconde proprietà di resistenza al preimage non contano: è solo la resistenza all'anteprima che è importante:

for essentially all pre-specified outputs, it is computationally infeasible to find any input which hashes to that output

Non è possibile dimostrare che una funzione di hash autocostruita abbia tali proprietà senza gli occhi di altri crittografi per esaminare correttamente il tuo algoritmo.

Un algoritmo di hashing sicuro non può essere annullato se viene utilizzato con un salt. L'unico modo in cui un utente malintenzionato può scoprire la password ottenendo l'hash e il suo sale è indovinando la password. Cioè, avranno hash ogni ipotesi e scopriranno se ha hash alla stessa password quando viene aggiunto il sale.

L'utilizzo di password_hash in PHP senza il parametro $algo utilizzerà sempre l'algoritmo più sicuro al momento. Un algoritmo di hash sicuro è lento in modo che se un utente malintenzionato riesce a ottenere gli hash e il sale che devono attendere a lungo per eseguire le proprie ipotesi di password. Quindi un vero utente che accede deve attendere 1 * dell'algoritmo lento, diciamo un secondo. Un utente malintenzionato che prova 10 milioni di tentativi di password dovrebbe attendere 10.000.000 di secondi. Dovresti presumere che abbiano un hardware migliore di te, quindi in realtà queste matematiche non reggono - il punto è che un algoritmo lento rallenterà sufficientemente il loro attacco. L'attuale algoritmo password_hash , che è bcrypt, si è dimostrato lento senza alcuna scorciatoia disponibile al fine di scoprire se una determinata password indica l'hash della password.

    
risposta data 28.07.2015 - 17:36
fonte

Leggi altre domande sui tag