Protezione degli hash di valori enumerati brevi

The salt must be common for all the records.

Questo è noto come "pepe", non un sale.

the attacker could easily iterate all the possible values

Se lo spazio di ricerca è abbastanza piccolo da poter essere forzato brutalmente anche con un hash di costo elevato come bcrypt , allora ti stai affidando interamente alla segretezza del "pepe" per prevenire la forzatura bruta. In questo caso, potresti anche usare un HMAC con una chiave segreta. Usare un HSM per memorizzare una chiave casuale e gestire l'HMAC è quanto di meglio si possa ottenere.

Tieni presente che, poiché hai bisogno di cercare l'hash, gli stessi dati avranno sempre lo stesso valore di hash. Poiché la risposta di Kevin va più nel dettaglio, i valori hash duplicati possono essere correlati con altri dati per divulgare le informazioni.

Anche se sarebbe ideale per gli hash essere irreversibili, non è semplicemente possibile con un piccolo spazio di messaggi. Il meglio che puoi fare è assicurarti che solo l'HSM possa essere usato per invertire gli hash. Ciò aiuta a prevenire perdite di dati, ma devi comunque fare in modo di assicurarti che il livello dell'applicazione non possa essere forzato bruto.

[Questo più di un lungo commento che una risposta]

Hai taggato la domanda crittografia , ma stai parlando di sali e hash. Come si fa notare, le funzioni di hash non sono adatte a proteggere un piccolo spazio-messaggio (esempio tipico: i messaggi sono "Sì" o "No"), quindi è necessario imbullonare tutti questi sali e peperoni e le chiavi HMAC.

Tuttavia, la crittografia corretta, in particolare i codici a blocchi, sono progettati per essere sicuri anche su uno spazio di messaggi "Sì / No". C'è qualche ragione per cui non puoi usare la vera crittografia AES? (per i punti bonus, memorizzare la chiave di decrittografia AES sull'HSM).

Prenderò la risposta breve: non puoi fare ciò che vuoi. Non proprio.

Si desidera memorizzare una serie di valori facilmente ipotizzabili nel database, crittografati, quindi nessuno che interrompe il database può sapere cosa sono ... ma si desidera essere in grado di cercare nel database tale termine. Ciò significa che ogni "tag" sensibile deve crittografare allo stesso identico valore.

Ok, che ne dici di un esempio.

Name     MedicalStatus
----------------------
Kevin    Dying
Bob      Alive
Charlie  Dying
Diana    Alive
Elaine   Alive
.... followed by 10k more rows of 'Alive' or 'Dying'

... quanto più sicuro è avere:

Name     MedicalStatus
----------------------
Kevin    dk3jnnd832jj3fd
Bob      cx32d89dh32gf1x
Charlie  dk3jnnd832jj3fd
Diana    cx32d89dh32gf1x
Elaine   cx32d89dh32gf1x
... followed by 10k more rows of either 'dk3....' or 'cx32d...'

Non devi nemmeno "decifrare" i valori. Devi solo indovinare - hai detto che erano facilmente comprensibili, dopotutto - e hai incrinato ogni altra voce corrispondente nella tabella. Non importa quanto sei esagerato nel cercare di oscurare quei valori e quanto sia "sicuro" delle tecnologie che usi, sarà piuttosto ovvio dal punto di vista dell'attaccante che cosa sta succedendo.

(Diamine, se sono qualcosa come me, lo vedranno come un puzzle divertente, obbligatorio link ) o, se sono pigri, creeranno solo pochi record nel database usando il livello dell'app per vedere come vengono memorizzati i loro valori.

Quindi, quello disse ... cosa puoi fare?

Opzione A : elimina il requisito di query veloce. È possibile utilizzare il sale effettivo (non il pepe) e rendere le voci protette utilizzando un algoritmo di crittografia reversibile. Ma il rovescio della medaglia è, come hai capito, che le ricerche dovrebbero decifrare ogni voce durante una ricerca.

Opzione B : sicurezza per oscurità. Sì, sai che questa opzione sarà brutta (di solito la sicurezza dell'oscurità lo è). Ma potresti creare un campo e chiamarlo un hash - ma semplicemente XOR i suoi dati sulla colonna sensibile per rimescolarlo. Quando esegui ricerche, non cerchi più il campo stesso, ma la combinazione XOR. Significa che non puoi più fare ricerche di indice (dovresti accontentarti di scansioni di indici) e non è esattamente una configurazione strong ... ma è almeno meglio che avere tutte le stesse voci con gli stessi identici valori.

Opzione C : ha solo gli hash ricercabili per la persona che sta eseguendo la ricerca. Aka, hash le voci utilizzando una chiave che è unica per ogni persona. Certo, questo significa che non ci può essere alcuna ricerca globale ; ma consentirebbe almeno la possibilità per un utente di trovare i loro record corrispondenti.

Opzione D : ripensamento e riprogettazione. Seriamente, le tue esigenze non stanno davvero arrivando qui, e ho la sensazione che finirai per creare un sistema che non è affatto sicuro. Il tuo obiettivo qui non è "Crea un sistema che soddisfi i requisiti X e Y nel modo più sicuro possibile". Il tuo obiettivo è: "Realizza un sistema sicuro che cerchi di soddisfare i requisiti X e Y." Se non riesci a raggiungere gli obiettivi in modo sicuro, non dovresti farlo affatto.

Credo che senza complicare la tua vita con la gestione di pepe / sale / altri meccanismi di hashing e dal momento che hai indicato che stai per implementare HSM, è meglio utilizzare la crittografia corretta per proteggere i tuoi valori enumerati.

HSM è un modulo hardware di calcolo crittografico con keystore protetto che funziona su un protocollo di interfaccia ben definito e difficile da compromettere.

Possibili chiavi simmetriche / asimmetriche che potresti usare sono:

• Symetric: AES, 3DES, Blowfish, ecc.
• Asimmetrico: RSA, DSA, Diffie-Hellman, ecc.

HSM può aiutarti in molti modi, tra cui la generazione di chiavi, il trasporto delle chiavi, la protezione della chiave di archiviazione, la gestione delle chiavi, le funzioni di backup / ripristino chiave, ecc.