it-swarm-eu.dev

In che modo un file chiave aumenta la sicurezza di un gestore di password?

Gestori di password come KeePass spesso hanno un'opzione per usare un file chiave oltre a una password principale.

Non capisco come questo aumenti la sicurezza.

(Nota: KeePass consente anche di utilizzare un file chiave invece di una password principale, ma in questa domanda ti sto chiedendo in particolare sull'uso di uno in aggiunta a un password principale.)

Dato che il database delle password non può essere decrittografato senza il file chiave, il file chiave deve essere archiviato da qualche parte, proprio come il database delle password stesso. Perché il file chiave è più difficile da raggiungere per un avversario rispetto al database delle password stesso?

22
HighCommander4

I metodi di autenticazione possono spesso essere suddivisi in tre aree: qualcosa che l'utente conosce, qualcosa che l'utente ha e qualcosa che l'utente è.

Le password sono qualcosa che l'utente conosce. L'utente lo memorizza nella sua testa e può "recuperarlo" dalla memoria come e quando è necessario.

Il file chiave agisce come qualcosa che l'utente ha. Idealmente, questo file chiave deve essere archiviato in un luogo sicuro.

Personalmente, ho copie del mio database di password ovunque. Il mio desktop ha una copia, il mio laptop ha una copia, il mio telefono ha una copia, il mio tablet ha una copia. Archivo il mio database delle password su Dropbox che mi consente di mantenerlo sincronizzato tra i miei vari dispositivi.

Tuttavia, non memorizzo il mio file chiave insieme con il mio database delle password. Il mio telefono e tablet ne ha una copia, perché non è possibile inserire un'unità USB in quei dispositivi, ma il mio desktop e laptop non lo fanno. Conservo il mio file chiave su un'unità USB che tengo sempre sulla mia persona. Questo rende leggermente più difficile per un utente malintenzionato ottenere il mio file chiave.

Utilizzare un file chiave in aggiunta a una password principale è utile, poiché aumenta la difficoltà a compromettere con successo il database delle password.

20
user10211

Il file della chiave contiene la chiave utilizzata per crittografare il database. Spesso è anche protetto da una password. Se non si dispone del file chiave, è impossibile ricavare la chiave dal testo cifrato per ottenere l'equivalente in testo normale. Quindi, se un utente malintenzionato dovesse ottenere il tuo database, dovrebbe comunque ottenere il tuo file di chiavi, qualcosa che hai . Se il file di chiavi è inoltre crittografato con una password (come dovresti), allora ha anche bisogno di qualcosa che conosci . Quindi questo è due fattori di autenticazione.

Se memorizzi il file di chiavi lungo il database, un utente malintenzionato dovrebbe "semplicemente" attuare un bruteforce o un dizionario per attaccare il file di chiavi (che è molto più piccolo e richiede molto meno tempo rispetto all'attacco all'intero database). Tuttavia, se si dispone di una password complessa, ciò dovrebbe comunque richiedere quasi per sempre (a seconda della casualità/entropia della password).

Ma l'aggiunta di un altro fattore aggiunge ulteriore sicurezza poiché un utente malintenzionato dovrà ancora ottenere due cose da te, anziché una.

È un po 'come conservare le chiavi su un portachiavi. Ma non conserverai la chiave accanto alla tua porta chiusa a chiave, giusto? Bene, questo è simile.

7
Lucas Kauffman

Oltre ad agire come "qualcosa che hai", l'opzione per utilizzare un file di chiavi consente una maggiore flessibilità negli altri due fattori ( "qualcosa che conosci" e "qualcosa che sei") senza dover implementare esplicitamente tale comportamento nell'applicazione.

Esempio 1: "Something you know" potrebbe essere eseguito attraverso un'abitudine o più forte la funzione di derivazione dei tasti di quella supportata da KeePass (specialmente compatibile con v1.x); quindi caricato come file di chiavi.

Esempio 2: "Something you are" potrebbe essere eseguito attraverso uno scanner biometrico che scrive una bio-firma che viene quindi eseguito attraverso una funzione Trapdoor e/o una funzione di derivazione chiave da caricare in KeePass che non ha una conoscenza nativa della biometria, in particolare sui sistemi operativi senza standard biometrico equivalente "TWAIN".

Esempio 3: "Something you are" nel senso più generico di dimostra di essere un essere umano * rigenerando il file di chiavi (o uno stadio di esso) da una digitazione umana in un'immagine CAPTCHA (o no o n altro possibili successori) memorizzati pubblicamente insieme il keystore.

Fondamentalmente, l'opzione keyfile può agire come un generico catch-all per qualsiasi fonte di entropia che puoi immaginare - entro il limite dello schema di crittografia del keystore sottostante ( 256 bit per KeePass).

* O HAL 9000.

4
LateralFractal

C'è un secondo vantaggio di un file chiave, separato dalla simulazione dell'autenticazione a due fattori (2FA). Sebbene la revisione della tua domanda suggerisca che la risposta a due fattori è ciò che stai cercando nella tua risposta.

Un altro motivo per non avere la chiave di crittografia derivata direttamente dalla password principale è consentire la creazione casuale della chiave anziché derivarne direttamente dalla password principale. Se creiamo la chiave con un CSPRNG e quindi crittografiamo quella chiave con una chiave di crittografia della chiave (KEK), possiamo assicurarci che la chiave principale abbia la piena forza della sua dimensione di bit. Questa è una chiave a 128 bit sarà davvero forte a 128 bit, anche se un individuo sceglie una password principale scadente.

Anche se questo non è obbligatorio per le chiavi simmetriche (come usato nei gestori di password), è assolutamente vitale quando si guardano i sistemi di chiavi pubbliche. In quei casi la chiave privata non può essere semplicemente nulla, quindi non può essere realmente una funzione di una password e un po 'di sale. Ecco perché per cose come PGP o SSH le chiavi vengono generate dal software e quindi crittografate con un KEK derivato dalla password.

Naturalmente la derivazione di KEK dalla password principale deve ancora essere "allungata" con una funzione di derivazione chiave come PBKDF2 o scrypt.

Due fattori, ma non autenticazione

Nota: il motivo per cui ho detto "simulazione autenticazione a due fattori" è perché in questi casi non esiste autenticazione. Invece c'è la decrittazione. Per molti scopi, la distinzione non ha importanza, ma ci sono casi cruciali in cui distinguere tra una password di autenticazione (o token) da un token di crittografia è enorme.

Nel caso di qualcosa come KeePass, che non sono basati sull'autenticazione (non stai dimostrando chi sei a un servizio che poi ti rilascia materiale in caso di successo), devi ottenere il tuo file chiave su ogni computer o dispositivo che devi usare i tuoi dati su. Quindi metterlo su una cosa USB potrebbe non funzionare se si desidera decrittografare i dati su un telefono. Potrebbero esserci dei modi per farlo con KeePass, ma data la mia (possibilmente imperfetta) comprensione dell'architettura, presenterebbe alcune difficoltà che dovrebbero essere superate.

4
Jeffrey Goldberg

Le risposte qui sono molto buone, ma penso che qualcosa dovrebbe essere notato qui in modo più esplicito:

Il file chiave nel database KeePass non è come altri metodi a due fattori utilizzati negli account online. il file chiave qui (e anche il plugin OTPKeyProv se qualcuno lo usa invece di) sono come la tua password.

Voglio dire, se qualcuno vuole forzare il tuo database KeePass non ha bisogno di avere il tuo file chiave o il tuo codice OTP perché KeePass ha usato questi elementi come la tua password per crittografare il database. quindi non c'è molto qualcosa che hai come gli account online qui in termini di sicurezza.

L'unico vantaggio di questi metodi è che il tuo database avrà un KEK migliore in termini di qualità/sicurezza usato per crittografarlo e se la tua password è di bassa qualità non influenzerà molto la sicurezza del database rispetto all'utilizzo della password stessa .

0
Ali