Utilizzo di un hash al posto dei dati utente

Question

Utilizzo di un hash al posto dei dati utente

#1 da (1 voti)
#2 da (0 voti)

2

Sto memorizzando i dati dei clienti e sono sensibili alla privacy e alla sicurezza dei dati. In alcuni casi, non ho bisogno dei dati reali, ma potrei lavorare con un hash dei dati. Ad esempio, nel caso di un'email di un utente. Non ho bisogno nella nostra applicazione per l'indirizzo email degli utenti tranne che per confrontare per l'uguaglianza per trovare i record sulla stessa persona.

Quindi per minimizzare l'esposizione di quei dati, stavo pensando di sostituire l'e-mail con un hash BCrypt dell'e-mail prima di salvarlo nel database - in questo modo non lo memorizzo, ma posso comunque confrontare come record, o se il cliente vuole cercare una particolare e-mail, può inserirla ed essere ancora in grado di cercarla.

Ma avremo 100.000 di record, quindi il costo computazionale di Bcrypt diventerebbe rapidamente un problema quando i record di riferimenti incrociati.

Sto pensando di usare solo l'MD5 inferiore poiché è più veloce, ma volevo controllare il mio modo di pensare:

La difficoltà ridotta di MD5 contro Bcrypt sconfigge lo scopo dell'hashing in primo luogo, o è un compromesso valido in questo caso?
Questo approccio in generale ha una presa di sicurezza o una scappatoia che potrei aver ignorato?

hash md5 bcrypt

posta ChristopherJ 28.06.2016 - 15:25

fonte

2 risposte

1

MD5 è migliore del testo normale, ma solo marginalmente.

Se usi bcrypt con un salt, per trovare tutti i record con email [email protected] dovrai hash quell'e-mail una volta per record con quel record unico salt. Questo potrebbe rapidamente sfuggire di mano e, come si nota nella tua domanda, non funziona.

Quello che puoi fare invece è usare un sale costante uguale per tutti i record. Quindi non è più chiamato un sale, ma un pepe. Il valore del pepe dovrebbe essere casuale e trattato con la stessa cura di un chiave crittografica , poiché senza di essa una forza bruta sugli hash è praticamente impossibile.

È importante capire che un pepe non è sicuro come un sale, dal momento che un forger bruto in possesso di esso otterrebbe la stessa velocità di non dover calcolare l'hash una volta per record come si fa durante la ricerca. Ma è molto meglio che usare un algoritmo veloce come MD5 o SHA-256.

Una nota pratica: non sono sicuro se tutte le implementazioni di bcrypt ti permettano di specificare tu stesso il sale, e tutte avranno l'aggiunta di sale nell'output. È necessario tagliare quella parte prima di memorizzarla, poiché il pepe non deve essere memorizzato nel database.

risposta data 28.06.2016 - 16:08

fonte

Leggi altre domande sui tag hash md5 bcrypt

Iniezione di pacchetti man-in-the-middle Che cosa significa "lo spazio di probabilità è sopra il lancio di monete di algoritmo M" significa?

score 0 · Accepted Answer

Ci sono due cose in corso con la mia interpretazione di questo. Hai un identificatore e un messaggio, e un cliente potrebbe aver bisogno di richiamare un messaggio, ma per farlo, avrebbero bisogno di un identificatore (sostitutivo) per mantenere il loro intento, qualcosa di abbastanza strong da non poter essere indovinato. Per esempio:.

MESSAGGIO ORIGINALE

FROM [email protected]
MSG: This product is giving me an issue

In conclusione, vorresti che il tuo client visualizzasse questo e qualsiasi messaggio per qualsiasi scopo, ma dal momento che non vogliono che i loro dati personali siano archiviati, stai cercando di creare qualcosa del genere:

FROM 7d9065d7076298c54b45b2672797cc7b
MSG: This product is giving me an issue

Se questo è il caso, la preoccupazione principale sarebbe se qualcuno potesse capire l'hash 7d9065d7076298c54b45b2672797cc7b (che è il risultato md5 di [email protected]). Per esempio:.

$ echo [email protected] | md5
7d9065d7076298c54b45b2672797cc7b

Sebbene md5 sia considerato insicuro, è perché può essere generata una collisione. In questo utilizzo, un attaccante produce poco nella creazione di una collisione. Dovrebbero essere in grado di determinare il valore dell'hash, non colliderlo. In pratica dovresti essere ok ma sarebbe più adatto per aggiungere un salt (var result = md5 (salt + string);) o semplicemente risalire l'hash a SHA512. Ricorda, l'obiettivo è proteggere l'identificatore (indirizzo email) che può essere eseguito in modo decente da un attacco standard / comune / semplice. Se sia in grado o meno di sopportare qualcuno con risorse / intenti è una domanda diversa.

Se intendevi un hash sia sul messaggio che sul mittente, ciò non è fattibile. Puoi cancellare il mittente e crittografare il messaggio. Anche nel farlo, se il sistema che ospita questi dati non è protetto da principi di privilegi minimi e vulnerabilità, diventa un punto controverso.