Perché non usiamo il nostro telefono con una password e poi inseriamo l'hash su un sito web come password?
In questo modo la password per il sito web sarebbe molto più complessa.
Aumenterebbe persino la sicurezza?
Esempio
Questo è essenzialmente identico alla semplice generazione di una password che non è hash, in termini di sicurezza. Non importa se usi il tuo nome per una password o il checksum dell'ora corrente; se la cosa che invii su Internet viene confrontata con una stringa memorizzata direttamente in un elenco sul lato server, allora la password non è stata sottoposta a hash utilmente.
Il punto in cui si memorizzano le password usando un hash sul lato server (anche se il "server" è locale) è che un buon algoritmo di hashing è a senso unico. Quindi, se la lista viene rubata, qualcuno che ha la lista non può ottenere direttamente le password. L'autenticazione con una password con hash richiede che un processo venga applicato alla stringa fornita e che i risultati siano gli stessi. Quindi, un set di hash rubato fornisce solo l'output di quella procedura, non i valori effettivi che concederebbero l'autenticazione.
Se l'hashing viene eseguito dal lato client, tuttavia, l'elenco sul lato server rappresenta i valori effettivi utilizzati per l'autenticazione. Il che significa che non è necessario alcun lavoro aggiuntivo per utilizzare quei valori per accedere all'app come qualsiasi utente una volta che l'elenco è stato divulgato.
Penso che dipenda da cosa fa il server, ma non aggiunge molta protezione in entrambi i casi (o è anche peggio). (Inoltre, l'utente medio sa come calcolare un hash sul cellulare? Mi sembra una seccatura.)
Ciò significa che il client invia H = hash(password) al server, il server cerca i client hash password H' nel DB e convalida il client controllando H == H' . Questo è veramente brutto. Ora, se si verifica una violazione del DB, l'utente malintenzionato può inserire la password hash archiviata nel DB per accedere. Rimuove essenzialmente il punto di hashing in primo luogo ed è come se la password in chiaro fosse archiviata.
Questo significa che il client invia H = hash(password) al server, il server cerca l'hash dei client hashed password H' nel DB e convalida il client controllando H' == hash(H) . Ora se si verifica una violazione del DB, l'attaccante deve controllare se hash(hash(guess)) == recovered_hash , quindi il costo per l'attaccante è di circa 2 volte quello che sarebbe senza hashing sul lato client (cioè l'attaccante può controllare le password più lentamente del 50% che non è molto una vittoria). La sicurezza in questo caso dipende ancora da hash che è una funzione (non invertibile) resistente agli attacchi di dizionario, l'hashing del lato client non aiuta molto.
Riassumendo, la cosa migliore da fare è che il client inserisca la password in chiaro, trasmetta la password al server tramite HTTPS e hash la password sul server con qualcosa come bcrypt o scrypt, memorizzando solo l'hash sul server. Il motivo per cui la tua costruzione non è un miglioramento è che il "seme" se non ottieni alcuna entropia ed è altrettanto facile (o non facile) da indovinare, stai solo aggiungendo uno stadio intermedio.
Aumenterebbe la sicurezza? No. Qualsiasi applicazione moderna memorizza già le hash delle password nel database. Ogni volta che viene effettuato un tentativo di autenticazione, l'input dell'utente viene sottoposto a hash e confrontato con qualunque cosa si trovi nel database. Principalmente ciò avviene con una crittografia a 1 via (l'hash non può essere decrittografato al suo valore grezzo).
Quando si crea un hash su un telefono cellulare, ci sono 3 problemi:
Non vedo alcun vantaggio per la sicurezza in questo modo. Ovviamente è possibile utilizzare un telefono cellulare in un processo Autenticazione a due fattori per aumentare la sicurezza di gli account utente.
Leggi altre domande sui tag authentication passwords hash