Come si può sfruttare l'uguaglianza di hash in cortocircuito?

6

Recentemente ho trovato un codice password che ha cancellato la password e poi l'ho confrontata con l'hash salvato in modo ingenuo: un personaggio alla volta, cortocircuitando non appena è stata trovata una non corrispondenza. Abbiamo convenuto che si trattava di un bug di sicurezza e l'abbiamo risolto.

Tuttavia, questo codice ha stuzzicato la mia curiosità: supponiamo che un utente malintenzionato sia in grado di scoprire i tempi della password controllando il numero di cifre hash corrispondenti. In che modo questo bug può essere sfruttato nella pratica? Capisco che la sicurezza dovrebbe essere profonda e non è necessario trovare un exploit pratico per prendere una misura di sicurezza - sto chiedendo solo per curiosità.

Ad esempio, l'utente malintenzionato potrebbe provare a estendere progressivamente l'hash un carattere alla volta. Ma se l'hash è composto da n cifre, l'hacker deve eventualmente estendersi da n-1 cifre a n cifre. Supponendo una buona funzione di hash, questo sembra richiedere un attacco pre-immagine completo. Supponendo che l'attaccante possa calcolare l'hash, che richiede che l'attaccante abbia il sale se ce n'è uno, questo attacco potrebbe essere eseguito principalmente lato client (date n cifre in base b, sono richieste al massimo n * b richieste al server ). Ma le funzioni hash sono scelte per resistere agli attacchi pre-immagine, quindi questo exploit è pratico?

    
posta Solomonoff's Secret 11.05.2018 - 14:05
fonte

1 risposta

3

Questa risposta su crypto.SE delinea l'attacco che Anders sottolinea nei commenti. Anche se c'è un sale è ancora meglio fare un paragone nel tempo semplicemente perché si presume che i sali siano informazioni pubbliche, anche se in pratica sembra improbabile che diventi un grosso problema a meno che tu non divulga il sale senza divulgarne il contenuto hash della password.

La tua ipotesi su questo attacco che richiede un primo attacco pre-immagine sull'hash sembra logica, ma ha un grosso problema: lo spazio pre-immagine che conta è lo spazio pre-immagine delle password hash, non dell'hash stesso (vale a dire il preimage di H(p) dove p è una password piuttosto che H(d) dove d è qualsiasi dato). Questo è un problema anche con un hash lento perché quello spazio pre-immagine può essere molto più piccolo, come ad esempio provare le 2 password 20 più usate (ad esempio 2 128 per l'hash stesso).

    
risposta data 11.05.2018 - 15:48
fonte

Leggi altre domande sui tag