Come impedire all'utente di indovinare la chiave (password), se ha accesso a tutti i dati (eccetto la chiave)

AES-128 (o superiore) è l'algoritmo di crittografia simmetrica raccomandato da utilizzare. Finché la chiave viene generata utilizzando un generatore di numeri casuali crittograficamente sicuro (pseudo-), allora non sarà pratico per l'attaccante alla forza bruta.

Se Il rilevamento di duplicati può essere usato come vettore di attacco, (vedi potenziale exploit descritto da @JohnDeters ); Assicurati di includere un vettore di inizializzazione. In caso contrario, lo stesso SSN sarebbe sempre crittografato allo stesso risultato e l'utente malintenzionato sarebbe in grado di rilevare (e verificare in modo casuale) i duplicati in questo modo.

Non codificare la chiave nel codice sorgente principale, ma, piuttosto, posizionarla in un file separato, in modo che il codice sorgente possa essere copiato in un ambiente di test, se necessario, e una chiave (non segreta) separata essere usato per tali ambienti.

Stai molto attento. Non ignorare il fatto che un utente malintenzionato può forzare le SSN dal database senza conoscere la chiave di crittografia.

Se l'utente malintenzionato può utilizzare il proprio sistema per crittografare un SSN, (magari registrando un utente, modificando il valore di SSN e guardando il campo SSN crittografato modificato nel database) può apprendere SSN crittografati semplicemente per tentativi e errore. Immaginalo mentre imposta l'SSN su 000-00-0000. Il sistema lo crittografa e confronta il valore crittografato con tutti gli altri SSN crittografati nel database. Se il suo valore di test corrisponde a uno degli altri valori, ha imparato l'SSN di quella persona. Quindi modifica il suo SSN in 000-00-0001 e riprova.

Dato i tentativi di 999.999.999, sarà in grado di costruire una "tavola arcobaleno" che contenga tutti i possibili SSN. Ma di certo non ha bisogno di fare tanto lavoro per realizzare un profitto.

La maggior parte degli attaccanti è opportunista. Non hanno bisogno di ogni SSN nel database per commettere frodi sull'identità, devono solo indovinare un SSN per iniziare a rubare. (Più SSN rubano, più ricchi possono ottenere, quindi ovviamente vogliono il maggior numero possibile.) Quindi forse hanno solo il tempo di eseguire il loro attacco per un po ', e saranno comunque soddisfatti di aver indovinato un po' .

Maggiore è il numero di persone nel database, maggiore è la probabilità che l'autore dell'attacco abbia più successo.

Inoltre, è molto più facile che indovinare casualmente. Molte persone non sono consapevoli che fino a pochi anni fa, SSN sono stati emessi dalla regione geografica .

Considera un attaccante dello Utah che vuole commettere una frode sull'identità usando un indirizzo Utah. Il suo attacco indovina solo i numeri compresi tra 528-00-0000 e 529-99-9999. Ciò richiede solo 2 milioni di ipotesi, non 1 miliardo, ed è probabile che abbia un alto tasso di successo sui tuoi clienti che hanno elencato Utah come stato nel loro indirizzo.

Lo spazio di ricerca per gli SSN è così piccolo che è facilmente ricercabile da un utente malintenzionato con risorse modeste. È necessario prendere ulteriori misure per proteggere i dati e i sistemi da questo tipo di attacco.

Sei fuori di testa in questo, e non dovresti tentare di costruire questo sistema senza ottenere l'assistenza di esperti.

Per prima cosa, non sembra che tu capisca la differenza tra una chiave crittografica e una password. Una chiave crittografica (ad esempio, per AES) è costituita da dati binari selezionati casualmente utilizzando un generatore di numeri casuali sicuro. Una password è una stringa testuale scelta dall'uomo e memorabile. Se usi una password invece di una chiave potresti aver sparato alle password, sono molto facili da attaccare con la forza bruta.

In secondo luogo, l'idea di codificare la chiave nel codice sorgente è terribile. La tua sicurezza di poter mantenere questo codice sorgente dalle mani dell'aggressore è sconsiderato.

Terzo: la crittografia di un SSN non impedisce necessariamente a un utente malintenzionato di scoprire di cosa si tratta. La ricerca mostra che utilizzando dati disponibili pubblicamente e alcuni modelli statistici, un utente malintenzionato può indovinare gli SSN di una persona con un alto successo se hanno il loro data di nascita e di nascita . Ho visto database in cui SSN crittografati appaiono fianco a fianco con la data di nascita e lo stato di residenza (la maggior parte delle persone vive nello stato in cui sono nati). O peggio, con le ultime quattro cifre SSN - la parte dell'SSN che è più difficile da indovinare!

In quarto luogo: secondo la risposta di John Deters, ti stai concentrando su ciò che un attaccante passivo può fare e non pensare a un attaccante attivo , che può inviare SSN in chiaro affinché tu possa crittografare e osservare i risultati crittografati. Al suo scenario di verifica aggiungerei la possibilità di contraffazione . A seconda di quanto si usi impropriamente la crittografia, un utente malintenzionato che conosce una coppia di testo cifrato / testo in chiaro potrebbe essere in grado di utilizzarlo per creare un testo cifrato che decrittografa in un testo in chiaro di propria scelta.

Oltre a questo, dato un buon cifrario, un utente malintenzionato nelle condizioni che descrivi non dovrebbe essere in grado di trovare alcuna informazione sugli altri testi in chiaro con una sola coppia di testo cifrato / testo in chiaro. Quindi non è questo il tuo problema.