Hash id utente in modo sicuro

Ti manca un modello di minaccia

Vedo due evidenti minacce, entrambe relative alla possibilità di interrogare il tuo database. Ce ne sono sicuramente altri (suggerimenti benvenuti):

• A - Un utente malintenzionato ha rubato il tuo DB (e il server salt) e desidera dedurre gli ID di Facebook di tutti i tuoi utenti
• B - un utente malintenzionato conosce le informazioni di Facebook di un utente specifico e desidera capire se esistono nel tuo DB (senza infrangere tutte le sue voci)
• C - Un utente malintenzionato con esattamente le stesse funzionalità può anche modificare il codice in esecuzione sul server, aggiungendo i ladri di informazioni che segnalano gli ID / password degli utenti durante l'accesso nel tempo

Esaminiamo ora le tue proposte

1. Use same server salt for all hashes.

Questo è ancora necessario per evitare tabelle arcobaleno predefinite, ma in realtà rallenterà solo gli attacchi effettuati per A o B. Assicurati di combinare con una funzione hashing lento per aumentare ulteriormente il costo di trovare i tuoi ID hash per A.

1. Encrypt the Facebook user_id instead of hashing.

Come decifri i tuoi ID quando un utente effettua l'accesso? Sicuramente la chiave di decodifica è memorizzata da qualche parte. È possibile archiviare la chiave di crittografia / decrittografia su un dispositivo fisico separato, in modo che i tentativi di decrittografia debbano avvenire sul server anziché realmente offline, poiché la chiave non può essere presa. Potrebbero esserci anche sistemi che possono avvisarti quando viene raggiunta una soglia di richieste di decrittografia ma questa non è la mia area, non so se esiste (basta notare che non puoi fare affidamento sul tuo server per farlo a causa della minaccia modello; il tuo server è caduto).

Si potrebbe anche memorizzare il sale in quel dispositivo, e in entrambi i casi la sicurezza è un fattore di quanto tempo ci vuole un utente malintenzionato per crittografare / hash un ID utente conosciuto con tutte le possibili chiavi / sali. Non sono affatto un esperto di crittografia quindi non posso dare alcun ordine di grandezza su ciò che è meglio fare, ma intuitivamente uno schema crittografico con una chiave grande è migliore (probabilmente anche più dispendioso dal punto di vista computazionale). / p>

1. Create dynamic salt as a function of the user_id - something like:

   Hash(Hash(user_id) + user_id)

    

Bene, questo è piuttosto inutile. Se vuoi complicare un attacco per la minaccia A, devi assicurarti che le informazioni aggiuntive siano indipendenti dall'ID che hai cancellato. Ad esempio, un indirizzo e-mail o una data di nascita varieranno da utente a utente, aumentando di fatto lo spazio di ricerca dell'input del tuo aggressore. La minaccia B è completamente inalterata poiché tutti i dati di Facebook sono già disponibili per il tuo aggressore.

Qui è difficile fare qualcosa contro B ... Se conoscono il tuo algoritmo di hashing e possono controllare se un hash specifico è nel tuo DB, non puoi fare molto. Ma ancora una volta è più probabile che le stesse funzionalità della minaccia C, che è ancora più grave. Ovviamente una buona pratica di hashing è importante per rallentare un attacco bruteforce offline ma devi anche considerare gli altri problemi che dovrai affrontare in uno scenario del genere. Dovresti scoprire come rilevare gli attacchi e avvisare i tuoi clienti che potrebbero essere stati colpiti da phishing o spam a causa di una violazione del tuo servizio (poiché un attacco motivato alla fine avrà recuperato tutti gli ID utente).

Non capisco davvero perché non è possibile cercare nel database una volta che l'utente ha effettuato l'accesso. Non è possibile salvare il nome utente come parte della sessione? (o il sale se è quello che ti serve).

Ovviamente questo sarà un po 'PITA dato che devi hash il nome utente ogni volta che vuoi fare una query. Ma per evitarlo (e se sei davvero interessato al hashing del nome utente), perché non usi lo stesso hash username come parte della sessione, o meglio, perché non aggiungi un id utente numerico in più allo stesso tabella utente e usa quel numero per fare le query nel tuo database?

Il tuo suggerimento di hashing sale dinamico suona molto simile a rolling your own .

Come nota di sicurezza, non credo che i nomi utente di hashing ti daranno una grande sicurezza, non so nemmeno se il sale ti aggiungerà sicurezza extra dato che credo che tutti i nomi utente dovrebbero essere diversi ... Inoltre, di solito, i nomi utente sono facili da indovinare, quindi credo che le tabelle arcobaleno saranno molto utili e quindi non aggiungerai poca sicurezza a nessuno.