Si tratta di uno schema valido per la memorizzazione delle credenziali dell'utente crittografate?

0

Stiamo creando un servizio che gestisce più account utente. Per questo motivo, abbiamo bisogno di memorizzare le credenziali per gli account di un utente utilizzando un algoritmo simmetrico in modo che possano essere recuperati affinché il server possa prelevare gli aggiornamenti per gli account. Tuttavia, non vogliamo mantenere le chiavi nel database, quindi ecco lo schema che abbiamo creato:

  • L'utente accede al nostro sistema utilizzando la sua password tramite una connessione SSL sicura. Ogni account utente ha un unico sale collegato al proprio account e viene utilizzato per cancellarne la password e verificarlo rispetto al database. La funzione di hash utilizzata per questo processo è bcrypt.

  • Se le credenziali di accesso dell'utente sono confermate, viene generata una chiave AES-128 simmetrica dalla loro password non crittografata e il loro unico salt e allegato alla loro sessione per decrittografare le credenziali degli account di terze parti memorizzati nel database.

Non sono un esperto di sicurezza quindi lo lascerò a voi ragazzi per distruggere il nostro programma. Lascia che la carneficina abbia inizio.

    
posta ReX357 09.05.2016 - 19:53
fonte

1 risposta

1

Non descrivi molto bene questo passaggio:

If user login credentials are confirmed, a symmetrical AES-128 key is generated from their unencrypted password and their unique salt and attached to their session to decrypt the credentials of the third party accounts stored in the database.

Esattamente come viene creata la chiave a 128 bit? Questo dovrebbe essere un processo molto lento, altrimenti fornirai un canale laterale per le password utente a forza bruta. Il modo in cui funzionerebbe è che un hacker metta le mani sul tuo database. Piuttosto che provare a forzare la forza bruta degli hash di bcrypt, che richiederebbero molto tempo, si arriva a lavorare sulle password crittografate. Semplicemente forza-forza la password dell'utente per ottenere chiavi che sembrano funzionare (ad esempio: il testo decodificato sembra una password, qualunque cosa significhi). Questo sarà un attacco rapido perché la crittografia è veloce.

È necessario rendere la creazione della chiave a 128 bit un processo lento. Il modo migliore per farlo è probabilmente usare bcrypt. Ma, come probabilmente avete capito, non si vuole usare il valore bcrypt che hai memorizzato nel DB per l'autenticazione in quanto non sarebbe un modo sicuro per archiviare le chiavi di crittografia. Ti suggerisco di tenere un secondo sale per ogni utente. Quindi usi quel salt, oltre alla loro password in chiaro, in una chiamata a bcrypt per generare la chiave di crittografia a 128 bit.

Quando un utente cambia password, è necessario cancellare o ricodificare tutte le password crittografate. Ciò è necessario perché gli utenti cambiano frequentemente le password quando sono preoccupati che la loro password sia stata compromessa. Quindi è meglio cancellare i dati che sono stati crittografati con la password compromessa. Questo, ovviamente, non aiuterà se l'autore dell'attacco ha già ricevuto una copia del database prima che la password cambi.

Un'altra misura di sicurezza che potresti aggiungere è il pepe (cerca "pepe" nella questa risposta ) la crittografia chiave. Il pepe dovrebbe essere una stringa di bit veramente casuale (no, il nome del tuo gatto non si qualifica) che hai memorizzato qualche altro . Cioè, non è nel database. L'utilizzo di un peperone impedirà a un utente malintenzionato di ottenere sia una copia del database che una password dell'utente, decrittografando i dati dell'utente, poiché avranno ancora bisogno del pepe. Ricorda che un peperone è tanto utile quanto sicuro. Inserirlo nel repository di origine è probabilmente una cattiva idea.

    
risposta data 10.05.2016 - 05:04
fonte

Leggi altre domande sui tag