Applicazione con accesso diretto al database: memorizza la chiave privata nel database

3

Un'applicazione utilizzata da più utenti accede direttamente al database (quindi un potenziale utente malintenzionato potrebbe accedere direttamente al database).

All'avvio dell'applicazione, l'utente si autentica utilizzando nome utente e password.

Ogni utente ha la sua coppia di chiavi. Questa coppia di chiavi DEVE essere memorizzata nel database.

Domanda:

Tenendo presente lo scenario sopra descritto in mente:

C'è un modo migliore di crittografare la chiave privata utilizzando una chiave derivata dalla password degli utenti?

    
posta Ratlos 04.02.2018 - 00:16
fonte

1 risposta

1

A patto che si stia utilizzando correttamente una modalità di crittografia autenticata approvata dal NIST (come AES-CBC e HMAC-SHA con KDF e IVs e e.t.c.) la rottura di questo dovrebbe essere difficile quanto semplicemente rompere un file crittografato. Ora, a seconda del caso d'uso questo potrebbe / potrebbe non essere sufficiente. Ti illustrerò un paio di altre opzioni a cui posso pensare io stesso, oltre ai potenziali vantaggi / svantaggi che la sicurezza può offrire.

Opzione 1: crittografia autenticata standard con chiave privata crittografata memorizzata nel DB

Questo (come accennato prima) sarà sicuro per la sicurezza, proprio come crittografare un file nello stesso modo, e dovrebbe essere difficile da rompere quanto la crittografia sottostante. Tuttavia, offre uno svantaggio principale: ciò consente a un utente malintenzionato di distruggere / modificare in modo irreversibile i dati della chiave privata, poiché semplicemente non fa parte del modello di minaccia di crittografia (si preoccupa solo che i dati siano segreti e non possano essere modificati senza essere rilevati) . Qui è dove propongo la soluzione n.2:

Opzione 2: DERIVE la chiave privata utilizzando la password dell'utente

Questa opzione comporta (in pratica) l'inserimento della chiave derivata in un PRNG e la generazione della chiave privata ogni volta (ogni volta che è necessaria la chiave privata, la si ricava dalla password dell'utente), questo ha il vantaggio di

  • non viene nemmeno memorizzato nel database,
  • la chiave privata (ovviamente) non può essere corrotta ora, perché non è memorizzata da nessuna parte.

Tuttavia, questa opzione potrebbe essere un po 'più rischiosa dell'opzione 1 a causa di due motivi:

  • I PRNG sono generalmente considerati inferiori in termini di sicurezza per bloccare le cifre (come AES)
  • A seconda della tua scelta, un attacco a forza bruta sulla password sottostante POTREBBE essere più veloce di cercare di interrompere AES
  • Il numero di possibili chiavi private è ora inevitabilmente molto più breve (a causa della natura di un generatore di numeri psuedorandom).
risposta data 04.02.2018 - 04:12
fonte

Leggi altre domande sui tag