Sto sviluppando un'applicazione online che richiede il numero di sicurezza sociale dell'utente.
L'applicazione non verrà elaborata sul server Web, quindi utilizzerò una chiave asimmetrica. Quindi un server Web compromesso non dovrebbe compromettere i dati.
Devo aggiungere dati casuali in quanto se un utente malintenzionato entra nel server web probabilmente può anche ottenere la chiave pubblica e la forza bruta forzare una corrispondenza tra l'utente e il SSN provando a crittografare tutti i SSN?
Questo ha senso ed è sufficiente?
Vogliamo che l'utente sia in grado di continuare un'applicazione utilizzando l'SSN per continuare e vorremmo anche assicurarci che non ci siano SSN duplicati usati.
Quindi il server Web deve almeno essere in grado di determinare che l'SSN corrisponda senza conoscere realmente l'SSN. Quindi possiamo memorizzare un hash in un'altra colonna simile al modo in cui vengono utilizzate le password. C'è un modo migliore?
Come posso proteggere dalla forza bruta? SSN ha solo circa 10 miliardi di valori possibili. Non ci vorrà molto tempo. C'è un modo per rallentare un attacco di forza bruta? Può richiedere fino a pochi secondi finché una forza bruta non diventa pratica.
La ricerca online fa apparire PBKDF2 e Bcrypt come una possibile soluzione. Ha senso? Questo rallenterà un attacco di forza bruta? Ci sono altri suggerimenti?
Voglio essere sicuro che non mi manchi qualcosa che ci lascerà vulnerabili. Mi rendo conto che non esiste una sicurezza al 100%, voglio solo implementare il meglio che è disponibile e conoscere il livello di rischio.
- Modifica Per chiarire come richiesto da Neil Smithline
-
È necessario decrittografare i dati. Tuttavia, la decrittografia non si verifica sul server web. La decifrazione avverrà su un server diverso, quindi ho intenzione di utilizzare chiavi asimmetriche per una misura di sicurezza aggiuntiva. Quindi i dati non dovrebbero essere decifrabili dal server web solo crittografati.
-
Abbiamo bisogno di essere in grado di cercare i dati sul server web per sapere se esiste già senza decryting dei dati.
A. Non è possibile utilizzare la chiave pubblica per abbinare il social in entrata. Poiché esiste una quantità molto limitata di SSN, circa 10B. Quindi aggiungeremo dati casuali per assicurarci contro un attacco di forza bruta. Vorrei proteggermi dall'attaccante compromettendo il web server e accedendo alla chiave pubblica.
B. Non è possibile utilizzare un semplice hash per la stessa ragione di A, forza bruta.
Invece stavo pensando di usare potenzialmente PBKDF2 o Bcrypt per rallentare una forza bruta.
Ha senso? Qualsiasi altro suggerimento.
- Modifica
Come Neil ha spiegato di seguito usando un hash e sale per cercare i duplicati non è pratico in quanto richiederebbe il controllo dell'intera colonna.
Quindi rimuoveremo il requisito di non avere duplicati.
Ciò che rimane ancora è, cosa possiamo fare per consentire all'utente di continuare un'applicazione utilizzando il proprio SSN senza la possibilità di decifrare il SSN e senza diventare vulnerabile alla forza bruta?
BCfypt sufice? Qualche altro suggerimento?
Posso sempre aggirare questo problema facendo registrare gli utenti e creare prima un nome utente e una password. Comunque preferirei evitarlo se potessi. Mentre crea aggiunge passaggi per l'utente.
Questo può essere ottenuto senza compromettere il loro SSN?