Perché i server memorizzano la password con hash anziché l'inoltro su chiave privata / pubblica

Se parli specificamente di applicazioni web (come per il tag), anche con hashing / crittografia della password sul lato del client sei ancora vulnerabile a man-in-the-middle come con l'invio di una password diretta.

Questo perché un attacco man-in-the-middle può sabotare lo script lato client dal suo passaggio dal server al client, per farlo fare qualcosa di diverso dal passaggio crittografato della password desiderato. L'utente finale non si sarebbe mai accorto (come richiederebbe un esperto di debug JavaScript per determinare che ciò fosse accaduto).

Per difendersi da MitM dovresti avere un codice attendibile integrato nel browser (o in un componente aggiuntivo) anziché in JavaScript fornito dal server. Potrebbe essere, ad esempio, Autenticazione del digest HTTP .

Tuttavia, in generale, se hai MitM contro l'applicazione, hai già praticamente perso. Anche con uno schema di autenticazione in stile digest sicuro, sarai comunque in grado di imitare qualsiasi azione che l'utente possa eseguire nell'applicazione, nobilitare la password all'impostazione / modifica dell'ora o semplicemente modificare l'interfaccia dell'app per richiedere la password. pagina.

Questo è il motivo per cui la maggior parte degli sforzi sono stati fatti per mantenere l'intero canale protetto (con SSL) piuttosto che per la protezione con password specifica. Non che SSL sia perfetto, ovviamente ...

Questo schema è ragionevole. Non c'è niente di terribilmente sbagliato in questo. Tuttavia, non sembra avere vantaggi chiari o convincenti rispetto alle "migliori pratiche" correnti: ovvero, l'invio di un nome utente / password su un canale autenticato da SSL, con la password memorizzata in formato hash sul server.

Non è più sicuro se il database del server è trapelato, perché la chiave pubblica dell'utente + salt (memorizzata nel database del server nel tuo schema) consente a un utente malintenzionato di montare attacchi di dizionario sulla password dell'utente allo stesso modo di una password hash fa.

Non è più sicuro contro gli attacchi man-in-the-middle, per le ragioni che spiegano @bobince.

Significa che la password dell'utente non lascia mai il proprio computer e non viene mai archiviata in chiaro nella memoria del server (nemmeno temporaneamente). Tuttavia questo probabilmente non è un vantaggio abbastanza grande da spronare all'adozione, in quanto non sembra fare molta differenza per i tipi di attacchi che sono prevalenti oggi.

In linea di principio, il tuo approccio potrebbe essere più sicuro contro il phishing, se fosse supportato nativamente dai browser, e se i browser fossero in grado di trovare qualche interfaccia utente che assicurasse che gli utenti digitassero la loro password solo nell'interfaccia utente del browser e non sarebbero ingannati nel dattilografarlo in un sito web. In pratica, però, i browser non supportano questo, e c'è un problema di gallina e uovo con la distribuzione (i browser non implementeranno qualcosa di simile finché molti siti non lo supportano, e probabilmente i siti non lo distribuiranno da soli senza il supporto del browser). Inoltre, non è del tutto chiaro come progettare un'interfaccia utente del browser per prevenire questi attacchi di spoofing e phishing.

In conclusione: è più complicato del semplice invio di un nome utente / password su SSL e non offre un vantaggio sufficiente a giustificare tale sforzo di sviluppo.