Supponiamo che tu abbia un sito web che fornisce un servizio di qualche tipo. Gli utenti possono accedere, possono memorizzare alcuni tipi di dati e sono disponibili vari tipi di crittografia per mantenerli al sicuro. Le password vengono salate e sottoposte a hashing, i dati degli utenti sono crittografati, le chiavi sono conservate in modo sicuro, va tutto bene.
Un giorno, i cattivi trovano una vulnerabilità nell'algoritmo di crittografia che stai utilizzando. I dettagli di ciò che la vulnerabilità è o quale algoritmo è ecc. Sono irrilevanti; la parte importante è che alcuni o tutti i tuoi dati non sono più così sicuri come è stato - è ora possibile nella pratica reale recuperare i dati dell'utente dai dati crittografati che hai archiviato.
Come gestisci questa situazione?
Nel caso delle password, puoi semplicemente invalidare le password di tutti, emettere notifiche di reset e sperare che gli account di posta elettronica a cui hai appena inviato tali password non siano altrettanto vulnerabili ... è una buona idea?
Per gli altri dati ... Beh, è immagazzinato usando la crittografia reversibile, quindi suppongo che potresti eseguire la decrittografia e ricodificarla usando il nuovo metodo non-rotto, ma per questo hai bisogno delle chiavi, che saranno presumibilmente (si spera) essere memorizzati come password, utilizzando la crittografia a senso unico, quindi sei quasi bloccato. Ovviamente il tuo modo di procedere più sicuro è quello di scrub i dati, ma ciò sembra piuttosto drastico, e i tuoi utenti probabilmente saranno un po 'seccati nel perdere tutti i loro dati di fronte a qualche rischio ipotetico che potrebbe essere molto piccolo e potrebbe non materializzarsi mai. / p>
Un pensiero che ho avuto è che potresti prendere i dati crittografati che hai e criptarlo di nuovo con un diverso (algoritmo non rotto), in modo da sapere che non può essere recuperato usando la nuova vulnerabilità, e poi tempo di accesso dell'utente, utilizzare il vecchio metodo seguito dal nuovo metodo e, se funziona, cancellare il campo e memorizzare una nuova versione che utilizza solo il nuovo metodo. Con gli hash salati, dovresti conservare anche i vecchi e i nuovi sali, ma non è un grosso problema. Quindi, la tua tabella necessiterebbe di una colonna aggiuntiva per un flag che ti permetta di sapere se quell'utente è stato migrato o meno al nuovo sistema e, nel caso di hash salati, un'altra colonna per il sale extra. Funzionerebbe, o c'è una vulnerabilità in questo che non ho individuato? Sono consapevole che combinando due metodi di crittografia a volte può produrre una vulnerabilità che non è presente in nessuno dei due metodi quando usata da sola, ma se i tuoi dati attuali sono crittografati usando un metodo che ora sai essere insicuro, la mia teoria è che potresti inoltre trattalo come testo in chiaro, a quel punto aggiungere la crittografia può renderlo più sicuro.