È possibile utilizzare gli hash deliberatamente a bassa entropia per prevenire attacchi di dizionario?

3

Considera un sistema che riceve, ma non memorizza, una parte di informazioni sensibili X da un utente. Se volessi aggiungere un modo per ricordare quando un utente ha inviato la stessa X più di una volta, quale sarebbe il modo più sicuro per farlo? X non è utilizzato per altri scopi; non è una password.

L'approccio ovvio ma insicuro sarebbe archiviare tutti gli invii di X e controllare i duplicati. Un modo per renderlo più sicuro sarebbe calcolare un verificatore (bcrypt o simile) delle presentazioni. Generato correttamente, la mia comprensione è che ciò sconfiggerebbe gli attacchi precablati con le tavole arcobaleno.

La mia preoccupazione è con gli attacchi di dizionario. Se X è relativamente probabile, un attaccante determinato può probabilmente fare progressi lenti ma costanti contro il verificatore. Una soluzione a questo è di troncare deliberatamente il verificatore per aumentare il numero di possibili testi in chiaro che corrisponde. Poiché X non è una password, dovrebbe essere OK per aumentare il numero di falsi positivi (un duplicato rilevato quando non ce n'è). Ma dal lato dell'attaccante, potrebbero scoprire che è facile trovare un testo in chiaro corrispondente, ma ce ne sono così tanti che è impossibile stabilire quale sia l'originale.

In altre parole, se l'entropia del verificatore è significativamente inferiore all'entropia del testo in chiaro, l'insieme di tutti i testi in chiaro che corrispondono a un determinato verificatore dovrebbe essere molto più grande di se le entropie fossero di dimensioni comparabili. Quindi è impossibile stabilire quale testo in chiaro sia l'originale.

È un approccio valido? O è eccessivo se il verificatore è calcolato usando un algoritmo lento come bcrypt?

    
posta Alex Quach 11.08.2016 - 20:28
fonte

2 risposte

1

Hai detto che permetti a "X" di avere falsi positivi. Quindi puoi semplicemente rimuovere molta entropia e consentire falsi positivi, ma l'hacker potrebbe affrontare lo stesso problema se avesse ottenuto il tuo database.

Ma se '' X '' ha abbastanza entropia su se stessa (128-bit o 256-bit), l'attaccante non sarà in grado di ottenere ulteriori informazioni dall'hash (per esempio usando SHA-256 o SHA-3 ), e non avresti falsi positivi. Hash permetterebbe esattamente questa sola informazione - sono le nuove informazioni che ho ottenuto come questa.

Se la tua '' X '' non ha abbastanza entropia e / o accetti il rischio di avere falsi positivi, allora puoi tagliare anche il tuo hash (allora diventa il numero di falsi positivi che accetti di avere) .

D'altra parte quando si usa bcrypt e altri PKDF, trovo che ti bloccherai rapidamente dalle informazioni. Supponendo che le informazioni '' a '' arrivassero a te, non avevi altra scelta che iterare su ogni hash di bcrypt memorizzato e controllare se è '' a '', che (come i PKDF sono lenti) sarebbe inefficiente da controllare.

Inoltre, ricorda che il punto debole del sistema che passa solo alcune informazioni riservate è un attaccante attivo - quindi può semplicemente memorizzare ogni '' X '' che il tuo servizio ha ricevuto da quando è stato violato.

    
risposta data 11.10.2016 - 02:34
fonte
0

Sembra dipendere dai possibili valori di X.

Ad esempio, se X può assumere valore in un intervallo di 1 000 000 possibilità, è possibile calcolare un MD5 di X e memorizzare solo i primi 16 byte e mantenere un basso livello di rischio di collisione. Il paradosso del compleanno mostra che la probabilità di collisione è ((1000000 * 1000000) / pow (16,0,16,0)) * 100 0,0000054%

Se un attaccante vuole trovare antecedenti md5, deve scegliere tra almeno 18 446 744 073 709 551 616 candidati equiprobabili senza la possibilità di sapere se il suo tentativo è quello buono (che è quasi inutile). Quindi questa parte è ok.

Ma devi determinare quale percentuale di collisione è accettabile per X. 0,0000054% non è molto alto (non dici) ma quando succede, è un piccolo problema o uno grande? Se non riesci a gestire i falsi positivi sui valori X, gli algoritmi di hash non devono essere utilizzati, troncati o meno.

Ma, considerando quello che hai descritto, il tuo approccio sembra abbastanza strong. Non hai davvero bisogno dell'algoritmo hash crittografico, SHA potrebbe essere sufficiente per il tuo scopo.

    
risposta data 12.08.2016 - 00:45
fonte

Leggi altre domande sui tag