Ho visto questa funzione slowEquals() durante la lettura di Hash delle password salate - Eseguendo correttamente , che utilizza un livello di byte Confronto xor per evitare attacchi temporali. Mi stavo chiedendo se questo è ciò che fa anche Bcrypt per evitare gli attacchi temporali. Io uso Openwall PHPass che ha il suo CheckPassword() method che non sembra xor. Come si evita l'attacco a tempo?
La cosa interessante dell'hash è che anche una modifica di un bit all'ingresso cambierà completamente l'output. Tienilo presente! Come si collega alla tua domanda? Bene, sopportami un po '.
Nella grande maggioranza dei casi, l'accesso a sale implica l'accesso all'hash della password. Questo è particolarmente vero nel caso di Bcrypt poiché quasi tutte le implementazioni memorizzano il sale, l'hash e il conteggio delle iterazioni nella stessa stringa con delimitatori. Tieni questo in mente!
Poiché il confronto sta avvenendo sulla hash della password, e qualsiasi modifica alla password di input cambierà completamente l'hash risultante (ricorda?), la resa dell'attacco di sincronizzazione sarà l'informazione sull'hash stesso al meglio . Tuttavia, è solo vero se l'attaccante ha accesso al sale. Ricordi cosa abbiamo detto? Un accesso al sale implica l'accesso all'hash. Ciò significa che l'attacco temporale in questo caso è irrilevante .
Se l'attaccante non ha accesso al sale, allora l'attacco di cronometraggio darà (praticamente parlando) zero informazioni. In questo modo, l'utente malintenzionato darà zero vantaggio.
In conclusione: per gli schemi di hashing come Bcrypt, Scrypt, ecc., gli attacchi temporali sono irrilevanti. L'utilizzo di confronti come == e === non è un problema. Detto questo, utilizzare il confronto a tempo costante è una buona pratica come parte di una politica di difesa in profondità . In effetti, molte implementazioni di Bcrypt utilizzavano già un confronto sicuro per il tempo nel caso ( timingsafe_bcmp.c in py-bcrypt , ad esempio).
Aggiornamento:
Esiste davvero un modo per estrarre alcune informazioni sull'hash senza conoscenza di nessuno dei suoi componenti (sale, iterazioni o valore di testo in chiaro). È descritto in un commento di Oasiscircle
This can still leak parts of the hash using the early-exit byte comparison. Example: Attacker computes tons of hashes and stores them looking for a hash that starts with 0x00. Upon finding a plaintext with that value, send that plaintext, listen for timing on response. Do this for 255 more values until one value takes slightly longer. That's the first byte value of the hash created from the plaintext.
Detto questo, mantengo ancora la stessa opinione espressa nella risposta originale sull'irrilevanza dell'attacco temporale quando si utilizza uno schema di hashing come Bcrypt. Mentre c'è davvero una possibilità di un simile attacco, è estremamente irrealizzabile. I requisiti di calcolo e archiviazione per questo attacco sono enormi e continuano a crescere in modo esponenziale con ogni bit scoperto dall'hash.
bcrypt non confronta affatto gli hash, bcrypt solo hash. Se si confronta il risultato con un% ingenuo di$storedHash === $hash, allora sei (teoricamente) suscettibile agli attacchi temporali. Questo è stato sollevato in un ticket Github per PHPass , con la risposta:
I've looked into this previously, and all my research indicates that this is unnecessary when dealing with proper password hashing techniques. Even the article you link states, "Using one-way hashing should defeat this because it’s very hard to work backwards from timing leaks when the attacker derived input keeps changing (hashes to a different digest each time a byte changes in the original plaintext input)."
I'll be happy to look into this again, but these issues are related more to accidental data disclosure than brute-force password cracking when hashes are in use.
Quindi PHPass non tenta esplicitamente di impedire tali attacchi temporali e l'autore non ritiene che il problema sia un problema.
L'implementazione "ufficiale" di bcrypt per l'hashing della password in PHP è password_hash e password_verify , l'ultimo dei quali implementa un confronto xor a tempo costante . C'è un'implementazione userland per le versioni di PHP sotto 5.5.
Leggi altre domande sui tag php passwords bcrypt timing-attack