Anonimizzazione migliore di un semplice hash

0

Sto cercando di aiutare a anonimizzare gli utenti, ma di dare loro comunque alcuni controlli. Quindi questo è diverso da come dire, anonimizzando un set di dati in cui non hai mai bisogno di tornare agli utenti originali.

Lascia che ti faccia un esempio. Voglio che un utente entri con il suo indirizzo email per accedere al mio sistema, ma non voglio memorizzare l'indirizzo email. Voglio assegnare a quell'utente un UUID che userò. Tuttavia, se l'utente perde l'identificatore casuale è necessario essere in grado di reinserire il proprio indirizzo e-mail e quindi tornare nel sistema.

La risposta più semplice a questo è un hash. Ovviamente potrei memorizzare l'hash accanto all'UUID. Se perdono l'UUID possono tornare indietro e posso re-hash la password. D'altra parte, se il mio sistema è suddiviso, i cattivi possono semplicemente fare un attacco di dizionario su un elenco di indirizzi e-mail e quindi ri-identificare gli UUID.

In primo luogo, c'è un modo standard per farlo? bcrypt e PBKDF2 mi vengono in mente, ma ovviamente non posso memorizzare una tupla di <email, salt, iterations> senza rendere il lavoro degli intrusi ancora più facile.

Non mi piace inventare nuovi elementi di sicurezza, ma ho avuto un'idea. Fondamentalmente immagazzino <SHA512(email), salt, iterations> e poi immagazzino <PBKDF2(email, salt, iterations), UUID> .

In questo modo devono prima attaccare il dizionario alla prima tabella, e poi usare i risultati per fare singoli attacchi di dizionario su ogni riga della seconda tabella, il che dovrebbe rallentare.

    
posta Paul Fremantle 07.07.2016 - 19:47
fonte

2 risposte

1

Mantieni le cose semplici, se vuoi l'anonimato, non utilizzare la posta elettronica per gli accessi.

Fai in modo che l'utente generi una coppia di chiavi asimmetrica per autenticarsi sul tuo sistema, chiamala chiave di accesso .

Quando l'utente desidera inviare un messaggio al tuo sistema, l'utente genera una nuova coppia di chiavi asimmetriche, chiamala chiave dati . L'utente dovrebbe quindi firmare il proprio messaggio con la chiave dati e crittografare la chiave dati privata con la propria chiave di accesso pubblica indirizzata a se stessi. L'utente invierà la chiave dati privata crittografata, la chiave dati pubblica e il messaggio firmato.

Per modificare il messaggio postato, l'utente scarica la chiave dati crittografata, decrittografandola con la sua chiave privata. E poi firmano il messaggio con la chiave privata dei dati. Il tuo sistema sa che il nuovo messaggio è generato dallo stesso utente dell'originale, poiché entrambi i messaggi sono firmati dalla stessa chiave pubblica dei dati.

Fai attenzione:

  1. molte implementazioni di crittografia asimmetrica allegano l'ID della chiave di crittografia a un messaggio crittografato, per rendere più facile per il destinatario di un messaggio identificare quale chiave utilizzare per decodificare il messaggio. Assicurati di crittografare la chiave privata dei dati senza aggiungere questi metadati.

  2. un utente malintenzionato che riesce ad osservare chi ha scaricato quale chiave privata crittografata è in grado di osservare quale utente ha scaricato la chiave e fare una ragionevole ipotesi su chi sta facendo cosa. Puoi evitarlo forzando tutti gli utenti a scaricare tutte le chiavi private crittografate (o una parte ragionevole di esse).

Basically I store <SHA512(email), salt, iterations>

Se stai memorizzando il SHA512 dell'email degli utenti, non sarebbe facile identificare gli utenti come creare una tabella arcobaleno SHA512?

    
risposta data 09.07.2016 - 07:33
fonte
0

If the user loses the random identifier they need to be able to re-enter their email address and then get back into the system.

Per acquisire questa funzione, non hai altra scelta che memorizzare un hash dell'indirizzo email. Anche il Salt non può essere segreto perché l'utente ha già dimenticato tutto tranne il suo indirizzo email.

Gli indirizzi email sono a bassa entropia come le password, quindi utilizza un hashing della password (lento)

  • BCrypt è comunemente raccomandato , ma assicurati di eseguire un rapido hash SHA-2 sui dati di input, quindi l'input super-lungo non verrà troncato da BCrypt
  • PBKDF2 ma è meno resistente alla GPU perché ha requisiti di memoria inferiori.
  • SCrypt è migliore di BCrypt se hai un fattore di lavoro abbastanza alto. Altrimenti è peggio contro le GPU. (ancora, a causa di requisiti di memoria più alti o più bassi)
  • Il vincitore del Concorso di hashing password potrebbe essere persino migliore di quanto sopra, ma non ha ancora superato la prova del tempo, quindi non usarlo ancora. Si chiama Argon2 e ha impostazioni del fattore di lavoro separate per il tempo della CPU e il carico della memoria. (Bello!)
  • È possibile utilizzare SHA-2 ripetitivo al posto di PBKDF2 (non ancora resistente alla GPU), ma è più difficile implementare la ripetizione in modo efficiente (ovvero essere resistente alla forza bruta) poiché SHA-2 è in realtà uno Scopo generale (Veloce ) Hash.

La maggior parte di queste opzioni genera Salt casuale per impostazione predefinita, ma è necessario verificare se questo è il caso!

È meglio includere un po 'di pepe (~ 72 bit di entropia) prima dell'input prima dell'hashing. Il Pepper può essere uguale per tutti gli utenti, ma deve essere memorizzato in un file al di fuori del database, in modo che il componente non possa essere trovato tramite SQL Injection.

Assicurati che il tuo fattore di lavoro richieda circa 100 ms (con protezione DoS appropriata) sull'hardware di destinazione (sapendo che gli hacker useranno hardware più veloce per la forza bruta)

Ricorda che molto semplici indirizzi email potrebbero essere comunque forzati brutalmente , quindi non permettere che l'hash venga rubato! Inoltre, è importante che un utente malintenzionato possa verificare rapidamente la presenza di un determinato indirizzo email.

Sarebbe saggio esaminare altre precauzioni di sicurezza che puoi fare come Separazione degli utenti del database SQL per contenere potenziali attacchi SQLi. Assicurati anche che il tuo sistema sia sicuro in generale.

I don't like to invent new security stuff, but I have had one idea. Basically I store <SHA512(email), salt, iterations> and then I store <PBKDF2(email, salt, iterations), UUID>.

Non c'è alcun vantaggio nell'aggiungere complessità qui. Se vuoi che l'aggressore debba fare più lavoro, solleva il fattore di lavoro e usa Pepper come descritto.

    
risposta data 07.10.2016 - 15:35
fonte

Leggi altre domande sui tag