Ok quindi panoramica di base sull'ambiente che sto immaginando: Webapp con backb db che memorizza i dati sensibili, possibilmente phi; utente standard: passa l'autenticazione a causa di utenti non prenotabili.
La mia idea era quella di crittografare i dati delle righe in tabelle sensibili memorizzate in un db utilizzando una chiave derivata dalla password dell'utente (cioè l'hash pw usando un algoritmo diverso da come il pw è memorizzato in db: es. : blowfish (pw), encrypt w / key = md5 (pw)). In questo modo ho potuto memorizzare la chiave di crittografia in sessione (per consentire l'accesso agli utenti autenticati ai loro record senza rientrare in pw) senza aumentare il rischio di perdite di pw e potrebbe distruggere w / sessione e rigenerare al login.
I vantaggi:
- Mi sembra che un utente malintenzionato non possa utilizzare i dati se l'hanno rubato mentre era "a riposo", ovvero l'applicazione era chiusa o in un backup.
Svantaggi che posso già vedere:
- Se dimentichi la password, perdi tutti i tuoi dati.
- Diventa impossibile modificare manualmente i contenuti db, tutto deve essere autenticato con pw utilizzato per generare la chiave di crittografia.
- Non protegge i dati mentre esiste una sessione.
Cosa mi piacerebbe sapere:
- Mi manca qualche difetto fatale nel mio schema?
- Esiste un modo migliore per memorizzare la chiave di crittografia mentre la sessione è attiva?
Chiarimento:
Ok penso che forse non sono stato chiaro nella mia formulazione originale della domanda. Intendevo che avrei archiviato un hash crittograficamente sicuro della password (probabilmente usando blowfish) per l'autenticazione, il che significa che una collisione o bruteforce della password non sarà facile (a meno che qualcuno non rompa blowfish, che è sempre un rischio). Simultaneamente all'autenticazione (quando qualcuno inserisce la loro password in ogni caso) io avrei hash la password usando qualche altro algoritmo (probabilmente qualcosa come md5 dato che non penso che debba essere crittograficamente sicuro a questo punto) che poi verrebbe memorizzato nella sessione e utilizzato per crittografare / decrittografare le righe appartenenti all'utente che è autenticato per la durata della sessione.
I miei pensieri su una maggiore superficie d'attacco sono quindi:
- Se un utente malintenzionato compromette l'hash della password utilizzata per l'autenticazione, può semplicemente accedere all'applicazione normalmente ed estrarre i dati in questo modo.
- Se un utente malintenzionato compromette la crittografia dei dati db, allora ha tutto a quel punto e non ha senso ottenere la password. Tuttavia, se fossero in grado di estrarre la chiave di crittografia e per qualche motivo volessero accedere all'applicazione, non trarrebbero alcun vantaggio dagli attacchi di collisione su md5 perché non è l'hash utilizzato per archiviare / autenticare la password. E una collisione contro un hash è fondamentalmente garantita per non essere una collisione contro un altro algoritmo di hashing diverso.
Possibile rimedio di below vuln:
- genera una buona chiave crittografica pseudo casuale prima che i dati vengano memorizzati
- crittografare la chiave crittografica con password (non ho bisogno di trasformare la password per questa versione non credo)
- su login decrypt key e store key nella sessione
- usa la chiave per eseguire la crittografia / decrittografia sul resto dei dati
perché penso che questo potrebbe funzionare è che non puoi distinguere il testo in chiaro da un linguaggio incomprensibile in modo errato così la capacità di verificare se la tua ipotesi fosse corretta è persa, anche se hai un elenco di possibilità che non puoi dire se uno ha funzionato . Inoltre non ottieni aiuto per forzare la chiave di crittografia perché ora è un valore casuale appropriato.