Ricerca su dati hash

Question

Ricerca su dati hash

#1 da (4 voti)
#2 da (3 voti)

2

Abbiamo una richiesta per crittografare i dati personali dei clienti (e-mail, indirizzo, ecc.) Usiamo MySQL che non ha alcun TDE come MS SQL o Oracle. Quindi, insieme alla crittografia dei dati, è necessario preservare la funzionalità per interrogare direttamente questi dati (non LIKE). Quindi qualcosa di simile seleziona * da persona dove email='[email protected] '.

L'idea qui è di utilizzare l'hashing e assicurarsi che la crittografia non sia resa ridondante dalla scarsa funzione di hashing. Quindi, se usiamo bcrypt che ha un built-in salt casuale, dovrebbe andare bene. Il problema è che con salt random non possiamo costruire di nuovo lo stesso hash per poter eseguire query SQL. Se uso bcrypt ('[email protected] ') e restituirà un valore hash diverso non posso eseguire select * da person dove hash_email = bcrypt ('[email protected]'). Posso ottenere lo stesso valore di hash solo se utilizzo lo stesso sale (e fattore di lavoro). Ma avere sale a livello di applicazione non sembra essere un'ottima soluzione. Quindi cosa si può fare per questo?

Se avere un valore di sale per applicazione non è intelligente potrebbe essere un tipo di miglioramento se generiamo, diciamo, 1000 valori di sale casuali e li memorizziamo nel database? Se abbiamo bisogno di hash email, possiamo fare quanto segue:

ottieni una veloce funzione di hashing numerico e calcola, ad esempio, m = num_hash (email) mod 1000
vai alla tabella sale salta dove id = m
email di hash con questo sale email_hash = bcrypt (sale, email) e archivia nel database

Per la ricerca possiamo applicare la stessa routine, ottenere email_hash ed eseguire query. Immagino che num_hash (email) mod 1000 non dica molto sull'e-mail stessa. Avere 1000 sali casuali è meglio che avere solo uno.

Qualsiasi suggerimento sarebbe benvenuto

hash salt

posta MarkT74 20.09.2014 - 21:28

fonte

2 risposte

Leggi altre domande sui tag hash salt

Buffer overflow - canister terminatore La password alfanumerica della forza bruta utilizza JohnTheRipper

score 4 · Answer 1

Sfortunatamente, la protezione fornita utilizzando un sale diverso per ogni e-mail è progettata per prevenire esattamente lo stesso tipo di query che ti servono. Quindi, se hai bisogno di query efficienti, dovresti utilizzare lo stesso sale per tutte le e-mail o non usare affatto il sale.

La selezione di un sale basato sull'hash dell'e-mail non è più sicura rispetto all'utilizzo dello stesso sale. Per vederlo, è necessario capire che tipo di sali d'attacco sono progettati per proteggersi. Supponiamo che l'autore di un attacco abbia n hash per crack e un dizionario di e-mail m . Se ogni e-mail è sottoposta a hash con un singolo salt, tale attacker dovrà eseguire l'hash di ogni e-mail nel dizionario con ciascun salt, richiedendo calcoli hash n · m . Tuttavia, se si utilizza lo stesso sale, l'utente malintenzionato deve eseguire l'hash di ciascuna e-mail solo una volta, quindi sono necessari solo i calcoli dell'hash m . Se il sale è determinato deterministicamente in base all'e-mail, sono necessari solo i calcoli dell'hash m .

In generale, se le tue applicazioni consentono ricerche rapide via e-mail, l'utente malintenzionato può eseguire la procedura di ricerca su tutte le e-mail nel loro dizionario. Indipendentemente da come viene implementata la procedura di ricerca, se è veloce, l'utente malintenzionato sarebbe in grado di utilizzarlo per controllare rapidamente tutte le e-mail. Quindi, l'uso di sali correttamente (poiché vengono utilizzati per l'hashing della password) non è compatibile con le ricerche veloci.

score 3 · Answer 2

Prima di tutto, la crittografia non è hashing e l'hashing non è crittografia. Parli di crittografia e poi vai avanti su bcrypt, ma bcrypt è pensato per l'hashing delle password.

Se utilizzare l'hashing o la crittografia dipende dalle tue esigenze:

Se si dispone di dati che non è necessario conoscere, ma che è necessario verificare in seguito (ad esempio una password), è necessario eseguire l'hash. Se si utilizzano solo gli indirizzi e-mail per l'identificazione, ma non vengono mai utilizzati o visualizzati, è possibile eliminarli (anche se a me sembra strano). In pratica i dati che nessuno vuole sapere e che nessuno ha bisogno di sapere, anche se hanno accesso al database.
Se hai dati che devono essere mantenuti privati anche se qualcuno ruba un disco dal server, ma devi essere in grado di trovare ciò che legge, dovresti usare la crittografia del disco al posto di TDE (come dici tu, MySQL non ha TDE ). Non c'è bisogno di TDE in particolare.

Inventare la tua "funzione di hashing scadente" è come provare a riscrivere ssh in assembly perché non hai letto la sua pagina man e non hai notato che probabilmente ciò che vuoi esiste già.

Si noti inoltre che bcrypt è fatto per essere lento, letteralmente. Interrogare un database che è stato sottoposto a hash con i parametri bcrypt appropriati sarà terribilmente inefficiente. L'unico modo per aggirare la lentezza è usare parametri sbagliati, a quel punto si potrebbe anche eliminare completamente bcrypt.