[Divulgazione: lavoro per AgileBits, i creatori di 1Password]
Nella tua domanda, hai detto
Password web-server creates automatically an Account Key.
Sebbene possa sembrare che sia ciò che accade, un controllo più attento del cliente (e parte della nostra documentazione) ti farà sapere che la chiave dell'account è creata dal tuo cliente e non sul nostro server . Nessuna chiave generata dal nostro server.
Quindi non solo non archiviamo tali chiavi, ma abbiamo costruito le cose in modo che non abbiamo l'opportunità di archiviare tali chiavi.
Derivazione chiave a due segreti
Come il mio collega, @ julie-in-austin, ha spiegato in la sua risposta , questa chiave dell'account è parte della nostra Derivazione a due chiavi (2SKD) . L'altro segreto è la tua password principale. Entrambi i segreti sono necessari per ricavare le chiavi che vengono utilizzate per decifrare i tuoi dati. Nessun segreto è mai visto da noi.
Il punto principale di 2SKD è proteggerti anche se i nostri server sono compromessi. Ovviamente non stiamo pianificando per che i nostri server siano compromessi, ma dobbiamo pianificare nel caso che i nostri server siano compresi. Senza 2SKD i tuoi dati potrebbero essere utilizzati da un utente malintenzionato per lanciare un attacco di indovinamento della password master. Con 2SKD un simile attacco è impossibile.
Un po 'di storia
Da tempo abbiamo assunto l'atteggiamento secondo cui non vogliamo mantenere i tuoi dati in nessuna forma. Non possiamo perdere, utilizzare o abusare di dati che non abbiamo. Non avere dati sensibili dei clienti significa che non c'è davvero nulla che valga la pena rubarci. Quindi, quando volevamo offrire il tipo di condivisione sicura e flessibile (ci scusiamo per le chiacchiere sulle vendite, ma queste erano funzionalità che volevamo davvero aggiungere), abbiamo faticato su come farlo senza mantenere i dati dei clienti. (Sì, ci sono protocolli peer-to-peer che avremmo potuto sviluppare, ma avrebbe aggiunto una notevole complessità per gli utenti e avrebbe dovuto difendersi da un'intera altra classe di attacchi.)
Quindi due elementi erano nel nostro design per i team fin dall'inizio. In primo luogo, non tenere nulla "crackable". Secondo, non apprendere nulla di "crackable".
Abbiamo utilizzato difese come PBKDF2 per molto tempo per offrire una sostanziale resistenza ai cracking ai dati catturati (e lo è ancora oggi). Ma alla fine ci imbattiamo in un muro di guadagni marginali decrescenti nella sicurezza dall'aumento di tali cose. Volevamo qualcosa che significasse che ciò a cui aggrappiamo è inutile per il tentativo di cracking. Come ha detto Julie, la chiave dell'account (che non si avvicina mai al nostro server), significa che il tentativo di indovinare la tua Master Password in base ai dati in nostro possesso non è limitato dalla forza della tua Master Password, ma deve affrontare una sfida a 128 bit dal tuo Account chiave.
La seconda parte di questo è che non volevamo nemmeno essere in grado di acquisire qualcosa di segreto durante il processo di autenticazione. Quindi utilizziamo un protocollo PAKE (Key Authenticated Key Exchange) durante il login. Né noi (né chi potrebbe aver superato la segretezza fornita da SSL / TLS) può imparare qualcosa di utile durante il login.
Quindi, fin dalle prime sessioni di pianificazione, attraverso ciò che vedi, c'erano modi per assicurarti di essere protetto anche se siamo compromessi. Questo è al di là dei soliti (e ancora utili) meccanismi di cose come PBKDF2.