he could gain pretty much all of that from looking at the unobfuscated
source of our app.
Questa è SICURAMENTE una preoccupazione. Se questo è il caso, allora la tua applicazione ha sicuramente un grosso difetto di sicurezza. Questo potrebbe essere ovunque da password / chiavi codificate nel codice, alla scrittura dei propri algoritmi crittografici, alla semplice divulgazione di informazioni solo a causa del modo in cui il codice viene scritto.
Una pratica consolidata nella comunità di sicurezza è stata che anche se il codice è stato reso pubblico, non dovrebbe avere alcun impatto sulla sicurezza dell'applicazione. Allo stesso modo, gli algoritmi crittografici e le loro implementazioni sono di dominio pubblico e vengono continuamente esaminati dalla comunità di sicurezza. È solo dopo tale scrutinio che vengono dichiarati "sufficienti" per l'uso per vari scopi ben definiti.
Detto questo hai due difetti MAJOR:
- La funzione Pseudo casuale non è un modo sicuro per ricavare una chiave e IV. Ciò che è necessario utilizzare è una funzione di derivazione chiave (KDF), che è implementata nella maggior parte delle lingue.
- Devi ricavare una chiave e una IV da un segreto , come una password o utilizzare un algoritmo asimmetrico in cui la chiave privata viene utilizzata per la decrittazione che avviene essere segreto L'ID utente NON è un segreto .
Ci sono anche due posti in cui è necessario crittografare i dati:
- Cifra quando viene inviato da un utente all'altro.
- Crittografa per l'archiviazione sul dispositivo dell'utente.
Non so quale di questi due avessi intenzione di usare. Per il primo caso, puoi utilizzare le chiavi simmetriche o le chiavi asimmetriche. Sebbene le chiavi asimmetriche siano diventate di fatto standard, più recentemente, alcuni esperti di sicurezza (come Bruce Schneier) hanno raccomandato di preferire tasti simmetrici su chiavi asimmetriche , ma dovrai valutare quale è sufficiente per le tue esigenze.
In ogni caso, quando si utilizza un algoritmo simmetrico, l'uso dell'ID univoco dell'utente non è sufficiente poiché gli ID univoci sono generalmente noti. È possibile utilizzare la password dell'utente e quindi derivare una chiave e IV per la crittografia utilizzando una funzione di derivazione della chiave (KDF). Troverai i KDF già implementati molto simili agli algoritmi di crittografia. Vorresti utilizzare un salt random con un numero elevato di iterazioni (le raccomandazioni variano, ma ho trovato che > 10000 è in genere abbastanza veloce e considerato ragionevolmente sicuro). È quindi possibile incorporare il sale non crittografato e il numero di iterazioni insieme al testo del codice in un unico pacchetto memorizzato. Quando devi decifrare, leggi quel sale e il numero di iterazioni dal pacchetto che hai archiviato, e usali con la password per ricavare la chiave e la IV e decifrare il testo cifrato.
Un approccio ancora migliore è quello di generare una chiave principale, che è possibile proteggere utilizzando il meccanismo sopra definito. Utilizzare questa chiave master per crittografare effettivamente tutti i dati. In questo modo, se l'utente cambia la password, tutto ciò che devi fare è decrittografare la chiave master e criptare di nuovo usando una chiave e IV derivata dalla nuova password invece di farlo con tutti i dati che l'utente ha archiviato.
È inoltre possibile utilizzare certificati (che sono chiavi asimmetriche) che si archiviano sul client e utilizzare per la crittografia / decrittografia, ma l'approccio generale cambierà leggermente. Senza sapere esattamente cosa stai cercando di crittografare, non voglio troppe possibilità.
Se chiarisci un po 'di più se stai cercando la crittografia tra due parti e criptando i dati a riposo, potrei essere in grado di tornare e fornire una raccomandazione migliore.