Opinioni sulla mia idea di implementazione "Crittografia a riposo"

1

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.

    
posta Camden Narzt 10.09.2014 - 08:10
fonte

2 risposte

-1

Il difetto più grande che vedo è che stai usando la password in due modi diversi, raddoppiando così la superficie di attacco. Nel tuo schema, un punto debole rilevato nel metodo di crittografia o l'algoritmo di hashing consentirebbe l'accesso completo ai dati dell'utente.

Ci sono tre passi che proponi:

First: We take the password and hash it using a known good algorithm. This is secure.
Second: We take the password again and hash it using MD5
Third: We take the MD5 hash and use it as an encryption key on some sensitive data

Come puoi vedere, l'hash MD5 della password è contenuto nella crittografia dei dati. Non viene salvato direttamente, ma è implicito all'interno della crittografia stessa. Proprio come una serratura della porta contiene un'impronta negativa della chiave richiesta per aprirla.

Ora, l'unico modo per garantire la crittografia è che la chiave sia troppo grande per la forza bruta. Tuttavia, la chiave è l'hash MD5 della password (sconosciuta). Ora, assumiamo che non mi interessa la password, voglio solo arrivare ai dati. Non devo indovinare la password, o trovare qualche debolezza con la crittografia visto che stai usando MD5 senza sale. Posso scaricare una tabella arcobaleno di hash MD5 e usarli come chiave di decodifica sui dati. Non appena i dati vengono decrittografati correttamente, so qual è l'hash MD5 della password. Se io sono interessato alla password, ho già avuto modo di trovare l'hash MD5! Inoltre, ogni utente con la stessa password riceverà lo stesso hash MD5 e quindi la stessa chiave di crittografia. Ora posso decifrare diversi dati sensibili degli utenti in una sola volta!

Mi sembra che la crittografia dell'intero disco possa proteggere meglio il tuo DB per i backup, in quanto il backup conterrà solo informazioni crittografate. Tuttavia, questo non impedirebbe un attacco attivo, mentre l'applicazione è in esecuzione.

    
risposta data 10.09.2014 - 12:24
fonte
0

L'unico vero problema di sicurezza che vedo con il tuo approccio è che parli solo della crittografia dei dati: non controlli che i dati crittografati non siano stati manomessi. Sarebbe possibile modificare i dati crittografati (dove hai appena preso un messaggio, applicato la modalità AES-CBC o AES-CTR ai dati), dove puoi indovinare la forma del testo in chiaro e alterarne il valore (tramite XORing come appropriato per il blocco modalità di cifratura per cambiare il corrispondente XOR dei dati in chiaro). Il modo per proteggersi da questo è utilizzare le modalità di crittografia autenticate che combinano la crittografia con un codice di autenticazione del messaggio (grosso modo un hash che è possibile costruire solo se si conosce la chiave segreta).

Vedo molti problemi di usabilità dal tuo approccio. In primo luogo, si perde la maggior parte del vantaggio di utilizzare un grande database per memorizzare le informazioni su molti utenti. Non è possibile aggiungere o aggiornare o modificare le informazioni crittografate per un utente se tale utente non ha effettuato l'accesso (ad esempio, poiché non è possibile utilizzarlo per un sistema di messaggistica o per un sistema che importa automaticamente le informazioni da un'origine esterna). Non è possibile creare indici, ricerche veloci, aggregazioni o join all'interno del proprio RDBMS che agiscono sui dati in una riga crittografata. Il pianificatore di query del database non può pianificare la distribuzione dei dati crittografati per eseguire il piano corretto. I dati non possono essere condivisi tra gli utenti che dovrebbero poter accedere alle stesse informazioni senza conservare copie ridondanti, il che va contro le regole di base della progettazione del database e ti lascerà con dati incoerenti (dato che puoi solo aggiornare le informazioni per l'utente corrente ).

Come hai detto, non c'è modo di trattare con un utente che dimentica la propria password senza cancellare tutti i suoi dati. Dovresti modificare questo in modo che questa funzione sia presente, poiché agli utenti reali sarà necessario reimpostare le password. (Puoi fare una sorta di sistema in cui memorizzi ogni chiave utente in modo crittografato con una chiave protetta da passphrase).

Infine, questo non ti offre molta sicurezza extra. Chiunque ottenga l'accesso come amministratore su quei sistemi potrebbe ottenere l'accesso ai dati protetti se fossero un po 'pazienti e ha semplicemente aspettato l'accesso dell'utente. Registrano semplicemente le richieste di rete in arrivo e acquisiscono le password dell'utente (a quel punto possono decrittografare i dati, tramite il sistema o da un dump del database). Non sembra molto più sicuro di avere un'applicazione ben sviluppata che si trova su un disco rigido crittografato (con backup crittografati), dove controlli e registrazione rigorosi degli utenti vengono eseguiti in tutti i passaggi.

    
risposta data 10.09.2014 - 23:32
fonte

Leggi altre domande sui tag