Passare al nuovo metodo di crittografia (senza perdere i dati?)

4

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.

    
posta anaximander 22.04.2013 - 13:38
fonte

1 risposta

4

Il modo migliore per farlo è semplicemente migrare la crittografia quando un utente esegue l'accesso o invalidare la password e i dati se ciò non si è verificato dopo alcuni mesi.

Quindi, per le password, l'utente si collega, conosciamo la loro password in chiaro, quindi calcoliamo solo il nuovo hash. Opzionalmente obbliga l'utente a scegliere una nuova password. Per i dati crittografati, l'utente effettua l'accesso, conosciamo nuovamente la loro password, quindi eseguiamo nuovamente la crittografia.

Il problema con la re-crittografia è che è ancora necessario conoscere la password per il nuovo codice da utilizzare. È anche soggetto a situazioni in cui il codice sottostante è debole contro gli attacchi di temporizzazione o di analisi di potenza.

Il problema con il ri-hashing è che tutte le vulnerabilità di collisione nel primo schema di hash sono perpetuate nel nuovo schema.

Quindi, per entrambi, è meglio aspettare che l'utente esegua l'accesso e quindi eseguirne la migrazione.

Un'alternativa è quella di double-hash o double-encrypt come misura temporanea, quindi eseguire la migrazione all'accesso. È più lavoro di sviluppo, ma funziona un po 'più sicuro.

    
risposta data 22.04.2013 - 14:58
fonte