Sì, il confronto delle stringhe (e/o la ricerca nell'indice) potrebbe, in linea di principio, perdere quanti byte iniziali identici l'hash della password memorizzato nel database e quello calcolato dalla condivisione della password immessa.
In linea di principio, un utente malintenzionato potrebbe utilizzarlo per apprendere in modo iterativo un prefisso dell'hash della password, byte per byte:prima trova un hash che condivide il suo primo byte con l'hash nel database, poi uno che condivide i suoi primi due byte e così via.
No, questo quasi certamente non avrà importanza.
Come mai? Bene, per una serie di motivi:
-
Un attacco a tempo può consentire all'attaccante di apprendere una parte dell'hash della password dell'utente. Uno schema di hashing delle password ben progettato (utilizzando un salt e key stretching ), tuttavia, dovrebbe rimanere al sicuro (supponendo, ovviamente, che le password stesse non siano facilmente intuibili) anche se l'attaccante conosce l'intero hash della password. Pertanto, anche se l'attacco temporale ha esito positivo, le password stesse saranno al sicuro.
-
Per eseguire l'attacco, l'attaccante deve inviare password di cui conosce il valore hash. Il valore hash dipende dal sale. Pertanto, a meno che l'attaccante in qualche modo non conosca già il sale, questo attacco non è possibile.
(È vero che, nella maggior parte delle analisi di sicurezza degli schemi di hashing delle password, si presume che il sale sia un'informazione pubblica. Tuttavia, questo è solo perché tali analisi presuppongono lo scenario peggiore di cui sopra, in cui l'attaccante ha già ottenuto una copia di l'intero database utente, salt, hash e tutto il resto. Se l'hacker non conosce ancora l'hash, non c'è motivo di presumere che lo conosca.)
-
Anche se l'attaccante conosce il sale, per eseguire l'attacco iterativo sopra descritto, dovrà generare password con hash su un valore con un prefisso desiderato. Per qualsiasi funzione hash sicura, l'unico modo pratico per farlo è provare un errore, il che significa che il tempo necessario per farlo scala esponenzialmente con la lunghezza del prefisso.
Ciò significa in pratica che, per estrarre un numero sufficiente di bit dell'hash da poter effettuare un attacco di forza bruta offline contro di esso (che non devono necessariamente essere tutti; solo più della quantità effettiva di entropia nel password), l'autore dell'attacco deve eseguire tutto il calcolo necessario per decifrare la password stessa. Per uno schema di hashing della password ben progettato e una password scelta in modo sicuro, questo non è fattibile.
-
Ciò che l'attacco iterativo può dare all'attaccante, in linea di principio, è la possibilità di eseguire la maggior parte del calcolo della forza bruta localmente alla fine, inviando solo un numero abbastanza piccolo di password al tuo sistema. Tuttavia, anche questo vale solo se ricevono informazioni dettagliate e affidabili sui tempi da ciascuno password inviata. In pratica, gli attacchi in tempo reale sono estremamente inefficienti e richiedono molte (spesso migliaia o milioni) query per produrre qualsiasi informazioni utili a tutti. Questo molto probabilmente annullerà qualsiasi potenziale vantaggio in termini di prestazioni che l'attacco temporale potrebbe fornire all'attaccante.
Questo punto è amplificato dall'utilizzo di uno schema di hashing della password di allungamento delle chiavi appropriato, poiché tali schemi sono deliberatamente progettati per essere lenti. Pertanto, il confronto delle stringhe nel database richiederà probabilmente una quantità di tempo trascurabile rispetto all'hashing della password in primo luogo, e qualsiasi variazione temporale causata da esso andrà quindi persa nel rumore.
