Generazione password - troppo primitiva?

Per la sicurezza , una cosa importante da tenere presente è che è possibile effettuare una ricerca esaustiva sulla password principale. Schematicamente, un utente malintenzionato che ha una password specifica del sito (ad esempio un malvagio amministratore su quel sito) può eseguire la tua applicazione Java (o un codice suo proprio che applica lo stesso algoritmo) e "provare" le potenziali password principali, per vedere se restituisce la password specifica del sito.

Se la tua password principale è grassa e casuale (diciamo, almeno 70 bit di entropia), allora questo non sarà un problema. Tuttavia, se la tua password principale è più "normale" (una password "strong" è, ad esempio, 45 bit di entropia), allora questa è una debolezza. La situazione può essere migliorata utilizzando hashing della password corretta :

• È necessaria la trasformazione dalla password principale alla password specifica del sito per essere lenta tramite l'uso di molte iterazioni.
• Hai bisogno di un sale . In questo caso, immagina che 10000 persone utilizzino il tuo sistema e che tutti abbiano un account su, diciamo, google.com (un esempio fittizio). Useranno "google.com" come "uso della password". Corrispondentemente, un malvagio amministratore di google.com potrebbe attaccare tutte le 10000 password principali in parallelo, con un sacco di costi di condivisione. Potresti usare il tuo nome come sale; i nomi non sono assolutamente buoni, ma questo migliorerebbe ancora significativamente questa situazione.

Questa è "forza bruta", ma con le password ricordate dall'uomo, la forza bruta tende a funzionare.

Per usabilità , ci possono essere alcuni problemi:

• Devi ricordare quale lunghezza della password hai usato su ogni sito.

• Alcuni siti hanno requisiti speciali e non esiste un insieme di regole "taglia unica" che funzioni ovunque (ad esempio, alcuni siti rendono obbligatorio l'uso di segni di punteggiatura, mentre altri vietano i segni di punteggiatura).

• Alcuni siti potrebbero richiedere modifiche della password. Per definizione, l'applet non può tollerare una modifica della password, a meno che non usi una nuova stringa "use", e quindi devi ricordarlo .

• Oltre ad essere subottimale per l'hashing della password, l'implementazione predefinita di% / or% di Sun / Oracle non è ben specificata e non è garantito che non cambi mai. Se Oracle decide di modificarlo a un certo punto, tutte le tue password andranno perse. Dovresti davvero fare affidamento su qualche algoritmo che non è soggetto a tali cambiamenti.

• Buona fortuna con il tuo codice Java sul tuo iPhone o iPad. Per una reale portabilità (compreso il fare girare il codice sulla macchina che possiedi tra 5 anni), potresti aver bisogno di implementare il tuo algoritmo in diverse lingue, perché non esiste una sola lingua per regolarle tutte. Ciò implica di nuovo l'uso di uno standard ben definito e non "ciò che Java sembra utilizzare per ora come algoritmo PRNG".

Per tutti i motivi di cui sopra, creare un "portafoglio di password" che non richiede spazio di archiviazione è impegnativo. Questo concetto è stato proposto e persino implementato molte volte, e potrebbe funzionare per i più siti, quindi puoi tollerarlo per il tuo utilizzo. A seconda del tuo contesto (quale sito usi, che tipo di hardware e sistema operativo possiedi ...).

La risposta di Tom Leek è un'eccellente revisione della diversificazione della password schema, quindi non tenterò di ripetere ciò che ha scritto nelle mie parole inferiori. In questa risposta mi concentrerò su un confronto con password univoche.

Le password uniche e sicure, generate in modo indipendente, hanno il vantaggio che una violazione di una password non rivela nulla sulle altre password.

In termini di usabilità, lo schema richiede che un dispositivo informatico generi la password del sito dalla password principale. (Suppongo che tu non possa riprodurre il calcolo di SecureRandom nella tua testa.) Questo dispositivo di calcolo deve essere considerato affidabile, dal momento che inserirai la password principale lì.

Con password univoche, puoi avere un archivio di password crittografato e utilizzare la password principale per decrittografarlo. Per raggiungere lo stesso livello di sicurezza, è necessario evitare gli attacchi di forza bruta dalla password principale, e questo è tutto. In particolare, se l'archivio delle password crittografato è pubblico, questo schema raggiunge lo stesso livello di sicurezza del tuo - una violazione della password principale rivela tutto. Quindi hai solo bisogno di sicurezza per la fase di decodifica, non della memorizzazione dell'archivio delle password crittografato. (Tuttavia, la sicurezza dello storage migliorerebbe la sicurezza dello schema.)

Pertanto, l'unico requisito per avere password indipendenti è una struttura di archiviazione non attendibile a cui un dispositivo può fare affidamento per il calcolo. In pratica, questo requisito è facilmente rispettato: il dispositivo che stai utilizzando per il calcolo ha spazio di archiviazione o ti fidi abbastanza per scaricare l'archivio delle password.

Il requisito per eseguire il backup e sincronizzare l'archivio delle password non è oneroso; data la connettività ubiquitaria di oggi, è in effetti meno vincolante dello schema di generazione della password. Esistono servizi per sincronizzare i file senza problemi su ogni piattaforma comune. È possibile sincronizzare l'archivio delle password, protetto con una passphrase strong, per i servizi con un livello medio di attendibilità. Se alcuni dei tuoi dispositivi sono più affidabili di altri, puoi mantenere l'archivio completo sui dispositivi più affidabili e un sottoinsieme costituito da alcune password meno importanti su dispositivi meno affidabili.

Sebbene il tuo approccio non sia fondamentalmente sbagliato, non ha un vantaggio pratico rispetto all'approccio più sicuro di password uniche ed è meno flessibile. Quindi usa password uniche.