Dici che non puoi fidarti di un gestore di password a causa dei rischi inerenti alla memorizzazione delle password . Ma non riesco davvero a capire dove sono i miglioramenti con le tue soluzioni:

1. Riservatezza:

   Un gestore di password normalmente dipende da qualcosa che hai (un file crittografato) e qualcosa che conosci (una password principale). Supponendo che si utilizzi una password master corretta e un gestore di password ben implementato, si presume che la sicurezza del file crittografato a riposo sia accettabile, e si può migliorare usando la memoria locale per il file se non si è sicuri della propria password principale. La vulnerabilità principale è che quando lo si utilizza un utente malintenzionato può leggere nella memoria del processo per estrarre il database decrittografato o la stessa chiave simmetrica utilizzata per la crittografia, ma questo presuppone che il sistema in cui si utilizza sia stato compromesso. p>

   Nel tuo sistema, hai ancora un gestore di password, quindi lo stesso attacco è possibile e devi solo aggiungere qualcosa che conosci (la tua password principale). Se il tuo sistema è compromesso, può essere intercettato anche con un keylogger o leggendo la memoria del processo. Inoltre, dato che è comune a tutte le password del sito, non lo cambierai facilmente, quindi è davvero vulnerabile alle intercettazioni.

2. Integrità:

   Il tuo sistema dipende da un gestore di password, quindi qui non puoi avere alcun miglioramento: se il vault della password viene modificato, termina con uno strumento non più utilizzabile e devi implementare lo stesso modo per identificare le modifiche indesiderate

3. Disponibilità:

   Il tuo sistema dipende da un gestore di password, quindi dovresti avere un backup del vault. Puoi sostenere che, avendo una password master aggiuntiva, il tuo sistema non è vulnerabile a una compromissione di quel backup.

   IMHO non è una buona pratica, perché la password principale è solo una cosa che conosci e che è improbabile che cambi perché dovresti cambiare tutte le tue password. Quindi stai per abbassare la difesa sulla parte qualcosa che hai perché pensi di aver migliorato la parte qualcosa che conosci , mentre IMHO non l'hai.

TL / DR: è improbabile che l'algoritmo venga adottato da un'importante applicazione di gestione password perché aggiunge davvero poca sicurezza, se presente. E come nei dettagli sull'implementazione della sicurezza, i punti in cui le vulnerabilità si nascondono, ti esorto strongmente a non fare rotolare i tuoi. Dovresti invece ripensare a quali sono i rischi inerenti all'archiviazione delle password e chiedi come puoi attenuarli.

Domanda originale

Con una sola password principale, sia per l'hash finale che per l'archivio chiavi.

Il tuo schema non aggiunge ulteriore sicurezza oltre a quello che i gestori di password standard già offrono.

Quindi diciamo che il file password del gestore password è trapelato. Generalmente, questi vengono crittografati utilizzando una chiave derivata dalla password principale. Quindi un utente malintenzionato dovrà crackare la password principale per ottenere le password specifiche del tuo sito.

Se la tua password principale e l'algoritmo di allungamento della chiave sono entrambi buoni, è un ordine alto. Ma per amor di discussione, diciamo che l'aggressore ha successo. Quindi conosce (a) la password principale e (b) tutte le password specifiche del sito. Niente le impedisce di calcolare l'hash che hai proposto.

Un attacco al tuo schema funzionerebbe esattamente come un attacco su LastPass, con l'aggiunta del calcolo di un semplice hash alla fine.

Domanda aggiornata

Con diverse password principali per l'hash finale e il keystore.

Qui stai usando due password. Il benchmark pertinente per il confronto è l'utilizzo di un normale gestore di password con una password lunga quanto le due password combinate.

Puoi discutere se questo è un vantaggio per la sicurezza o meno. Per ottenere l'accesso a tutte le tue password, un utente malintenzionato deve forzare prima la password del keystore e poi la password per l'hash finale. Per fare ciò, l'utente malintenzionato avrebbe bisogno di una password corretta nel keystore per confrontare i risultati con.

Se l'utente malintenzionato non possiede tale password, allora il sistema è migliore.

Se l'utente malintenzionato ha una password simile, un normale gestore di password è migliore. Forzare brutalmente due password di lunghezza n/2 è molto più facile che forzare brute una password di lunghezza n .

Quindi la mia raccomandazione sarebbe comunque quella di utilizzare un normale gestore di password con una password complessa. Se usi una password complessa, un utente malintenzionato sarà comunque senza modifiche.

Con un gestore di password, che sceglie casualmente le password del sito e le memorizza in un file crittografato:

• Un utente malintenzionato che ruba una singola password del sito generata casualmente dal manager non può quindi apprendere altro, perché è una password casuale, non correlata a nient'altro. Dal momento che molti siti praticano l'archiviazione di password non sicure (e difendersi da questo è in effetti uno dei motivi principali per l'utilizzo di una soluzione di gestione delle password!), Questa è davvero una buona protezione.
• Un utente malintenzionato che ruba una copia del vault della password crittografato ha bisogno di almeno per indovinare la password principale per utilizzarla. (Con alcuni gestori di password è anche necessario rubare una chiave di crittografia memorizzata separatamente dal vault, in genere il punto è che il deposito crittografato può essere caricato nel cloud, ma la chiave di sicurezza non lascia mai i dispositivi.)
• Un utente malintenzionato che riceve il file di password crittografato, la password principale e qualsiasi altra chiave richiesta accede inevitabilmente a tutte le tue password.

Con l'approccio "hash a master password", d'altra parte:

• Un utente malintenzionato che ruba una singola password del sito e nient'altro può usarlo per lanciare un attacco di cracking della password contro la tua password principale. Ciò è dovuto al fatto che site_password = hash(master_password, site_metadata) e site_metadata è un valore a bassa entropia che ammette gli stessi attacchi di ipotesi delle password. Dato che molti siti fanno uso di password non sicure, questo è molto preoccupante.
• Un utente malintenzionato che indovina la tua password principale non ha bisogno di rubare un file di vault della password per lanciare un attacco di indovinamento sul tuo site_metadata , che offre loro buone probabilità di scoprire le password del tuo sito.
• Alcuni sostenitori dell'hash della password master propongono anche l'uso di una chiave segreta come argomento dell'hash, o di memorizzare il site_metadata nei file in modo che l'utente non debba (mis) ricordarlo, ecc. fai tutto ciò, quindi non meno dell'approccio del vault crittografato, hai creato un file che l'utente malintenzionato potrebbe rubare per aiutare i loro sforzi.

Il vantaggio che i sostenitori dell'hash della password master più spesso rivendicano per il loro approccio è che non esiste un vault della password crittografato da rubare. Ma il problema con questa affermazione è che, questo è in realtà uno svantaggio -se non esiste un file di questo tipo, ciò significa che le password devono essere recuperabili senza tale file , dai dati che un utente può memorizzare. Pertanto un utente malintenzionato potrebbe essere in grado di attaccare lo schema senza rubare alcun file . L'hashing della password master è strettamente peggiore dei vault crittografati.