Posso fidarmi di un'implementazione di hash di sicurezza dopo averla testata con input casuali contro un'altra implementazione?

7

Diciamo che voglio usare un algoritmo di hashing di sicurezza, come bcrypt, e voglio usare una giovane implementazione bcrypt, ad es. chiamato libfancybcrypt , invece di un'implementazione ben stabilita.

Naturalmente, posso semplicemente generare alcune migliaia o milioni di stringhe casuali, cancellarle con libfancybcrypt e con la vecchia libreria ben stabilita e confrontare gli hash alla fine. Supponiamo, l'ho fatto e la nuova libreria in questione produce lo stesso risultato di quello ben consolidato per tutti gli input casuali.

La mia domanda ha due parti:

  1. Supponiamo che l'autore della libreria possa essere considerato affidabile. Dato il mio test di inserimento casuale sopra: quanto è probabile , che l'autore accidentalmente introduca un bug con l'effetto che ci sono input per i quali viene calcolato l'hash sbagliato?

  2. Supponendo che l'autore della libreria non possa essere considerato attendibile. Dato il mio test di inserimento casuale sopra: quanto è probabile , che l'autore abbia introdotto di proposito una backdoor di qualche tipo?

Correlati ma ancora diversi:

posta Lukas Kalbertodt 06.05.2017 - 11:39
fonte

2 risposte

5

Assume the library author can be trusted. Given my random input test above: how likely is it, that the author accidentally introduces a bug with the effect that there are inputs for which a wrong hash is calculated?

Essere fidati non implica che l'autore del software sia un programmatore competente che conosce tutte le possibili insidie. Questo significa che se ti affidi solo alla fiducia non puoi conoscere la probabilità di introdurre un bug. E poiché tale errore potrebbe verificarsi solo in rari casi come una condizione di competizione o qualche overflow di interi, non c'è alcuna garanzia che tu possa innescare il bug con i tuoi casi di test casuali.

Assuming the library author cannot be trusted. Given my random input test above: how likely is it, that the author has purposely introduced a backdoor of some kind?

Se la backdoor viene attivata solo con un input specifico, non lo scoprirai mai senza un'accurata ispezione del codice. E anche l'ispezione del codice potrebbe non essere d'aiuto, guarda gli esempi del Concorso C sottoterra . Ciò significa che è possibile introdurre una backdoor così furtiva. Ma ancora una volta, non è possibile attribuire una specifica probabilità a questo unicamente sulla base delle informazioni di cui l'autore non è fidato.

Can I trust a security hash implementation after testing it ...

Sulla base delle osservazioni precedenti, questa domanda non può essere risolta in modo definitivo. A parte questo, dipende molto da cosa usi la libreria: se è solo per ottenere dei checksum per rilevare i dati accidentalmente corrotti, i tuoi test potrebbero essere sufficienti. Se invece viene utilizzato per scopi in cui l'errore del software potrebbe portare alla morte, la fuoriuscita di segreti top o l'infezione da malware di infrastrutture critiche rispetto a tali test probabilmente non sono sufficienti, specialmente se non ci si fida dell'autore.

    
risposta data 06.05.2017 - 12:04
fonte
1

Finché l'hash risultante è uguale a quello attendibile, l'hash risultante può essere considerato attendibile. Immediatamente questo porta alle seguenti domande:

  1. È possibile fidarsi di tutti per gli hash risultanti?

Potrebbero esserci errori di implementazione, che si verificano solo in situazioni specifiche, un esempio potrebbe essere la gestione non corretta di /dev/random caratteri. Se si prova con un input casuale sufficiente e gli hash sono sempre uguali, ciò è molto improbabile. Pianificare una password specifica che porti a un hash non corretto non aiuterà l'aggressore.

Un altro problema specifico dell'hash delle password è la generazione del sale, potrebbe essere fatto con una fonte casuale che non è crittograficamente sicura, il che potrebbe rendere più facile il cracking. Questo può essere paragonato facilmente con te stesso.

  1. Ci possono essere effetti collaterali ?

Indipendente dal fatto che l'hash risultante sia corretto, il codice può fare tutto ciò che vuole, questo è principalmente un problema nello scenario di un autore malvagio, ma ci sono anche problemi con un'implementazione trascurata.

Ci sono attacchi facili da rilevare, ad es. un algoritmo hash non dovrebbe mai eseguire operazioni IO o accedere a Internet, naturalmente.

Molto più difficile da rilevare è il codice che può essere sfruttato, forse un determinato input provoca un overflow del buffer di proposito. Pertanto, mentre l'hash risultante è effettivamente sicuro, un utente malintenzionato potrebbe utilizzare il processo in modo improprio per attaccare il server. Tuttavia, questo non è correlato all'hashing, si applica a tutte le librerie di terze parti.

Un altro effetto collaterale facilmente supervisionato è che, se il codice legge da /dev/urandom invece di %code% , potrebbe scaricare l'origine casuale e bloccare il server se è usato eccessivamente.

➽ Personalmente preferisco usare una libreria non affidabile che offre un algoritmo sicuro, invece di usare un algoritmo non appropriato da una libreria attendibile. Naturalmente dipende dall'importanza del tuo servizio, ed è sempre una buona cosa controllare da te la fonte (gli algoritmi di hash non sono tanto codice).

    
risposta data 06.05.2017 - 14:21
fonte

Leggi altre domande sui tag