Perché i sistemi che eseguono l'autenticazione tramite password effettivamente inviano la password sul filo?
Perché non basta che il server rilasci una sfida e il client append aggiunga la sfida alla password e risponda con il suo hash SHA256, per proteggersi dalla perdita di password MITM?
C'è qualche vantaggio nell'invio effettivo della password? (Sembra ad esempio che SSH faccia questo? Perché?)
(domanda con risposta personale ...)
Credo che ciò sia dovuto al fatto che non puoi salare e cancellare la password sul lato server.
Si noti che la salatura è ancora necessaria qui perché se la password sul lato server viene rubata, può ancora essere utilizzata per il login anche nello scenario di risposta alla sfida.
Il motivo per cui le password inviate nel testo semplice o hash sono principalmente storiche. Ai vecchi tempi, quando usavamo terminali stupidi su linee seriali (dagli anni '70 agli anni '80), erano possibili solo soluzioni di testo. Beh, una sola password come S / Key esisteva anche ma tu avevi bisogno dell'elenco di copie cartacee con te ...
Poi è arrivata l'era di PC, Windows e Lan Manager . I ricercatori di Microsoft sapevano che le reti ethernet erano troppo facili da spiare, quindi decisero di scambiare solo sfide. La controparte era che era necessario memorizzare la password in una forma invertibile sul server.
L'uso di crypto è diventato più popolare con SSL, e molti protocolli sono stati adattati per usare canali crittografati (HTTP - > HTTPS per esempio). E gli amministratori hanno riscoperto i vantaggi dell'archiviazione degli hash sui loro server: se il database delle password è compromesso, hai tutto il tempo per cambiare le password.
Questo è il motivo per cui oggi le best practice sono lo scambio di password su canali criptati e l'archiviazione degli hash salati sui server e il motivo per cui sono esistite altre pratiche ...
La ragione principale potrebbe essere che qualunque cosa tu faccia dal lato client, può essere facilmente aggirata se non stai usando una connessione HTTPS crittografata. Il JavaScript può essere modificato o rimosso completamente da un utente malintenzionato ManInTheMiddle.
Quindi l'unica cosa su cui puoi fare affidamento è la connessione HTTPS / SSL crittografata. Se non hai la connessione crittografata, tutte le azioni sul lato client sono piuttosto inutili, se fai hai una connessione HTTPS, le azioni sul lato client fanno poco per migliorare la sicurezza.
Questo vale in genere per i siti Web, è un altro caso in cui l'utente ha installato un software client sul suo computer. Con un software client installato, non è necessario scambiare codice (JavaScript).
Hai qualche problema lì.
Il server deve avere la tua password per convalidare l'hash che gli hai inviato. Mentre gli account SSH sono configurati localmente sul sistema prima dell'accesso remoto, la tua web app comune avrà un modulo di registrazione, e in questo caso dovrai inviare la password in testo normale, vanificando lo scopo dell'autenticazione digest suggerita.
Lo stesso vale per la modifica della password.
Il secondo problema è che, se si utilizza un metodo di trasporto non protetto, posso ancora MITM e iniettare qualsiasi javascript mi piace sulla pagina web, ottenendo il nome utente, la password e tutto il resto.
MITM è un vettore di attacco ben compreso e ha già una soluzione: TLS.
In questo modo l'intera pagina verrà crittografata e firmata, quindi un eventuale utente malintenzionato non può vedere o modificare nulla, proteggendo l'intero flusso di dati andando avanti e indietro e rendendo l'autenticazione del digest ridondante.
Why do systems that do password authentication actually send the password over the wire? Why not just have the server issue a challenge...
Lasciatemi invertire la domanda. Cosa otterresti inviando la password via cavo? La risposta sarà spesso nulla.
Il luogo principale in cui utilizziamo la password è su Internet. Quando visiti una pagina web, questa pagina è controllata dal server e quindi puoi considerarla un'estensione del server. Se il server è compromesso o è malvagio, non appena digiti la password nella pagina, puoi considerarla compromessa e questa password dovrebbe essere modificata.
Nella tua domanda ti sembra di preoccuparti dell'attacco MitM, ma considera solo il MitM che può essere aggiunto quando invii il modulo e non quando ricevi la pagina, ma entrambi sono letali. Non importa se la tua password non è "supposta" da inviare o meno, non appena viene digitata è la stessa cosa.
Quindi è totalmente inutile utilizzare l'autenticazione challenge-response su una pagina web?
Se usi TLS, direi di si. Ricorda che il client è solo un'estensione del server.
Se non si utilizza TLS, può essere di aiuto contro l'intercettazione passiva, ma è comunque inutile contro il MitM attivo; dove puoi modificare il contenuto della pagina. Il fatto che il MitM attivo sia molto più difficile da estrarre rispetto alle intercettazioni passive è stato un motivo che ha motivato la creazione di tale schema. Vedi autenticazione digest .
Why is SSH different?
Perché il server non controlla il client. Il client è completamente separato dal server. Ciò significa che quando ho digitato la mia password segreta nel client, anche se rispondo a una richiesta di un malvagio server, la mia password segreta è ancora al sicuro.
È la stessa cosa con la tua carta di credito. Lo smart chip della tua carta di credito contiene una chiave segreta che viene utilizzata per rispondere a una sfida-risposta ogni volta che effettui un acquisto. Questa chiave segreta è protetta anche se fai un acquisto da un terminale malvagio.
Nota: un vantaggio del meccanismo challenge-response è che consente all'utente di riutilizzare la stessa password con più server. Questo punto è necessario per la carta di credito, ad esempio poiché utilizzeranno molti terminali (server) e avranno solo una password.
Il meccanismo Challenge-response funziona solo quando il server non controlla il client.
Ciò significa che se volessimo utilizzare l'autenticazione challenge-response per la pagina web, sarebbe necessario che fosse implementata a livello di browser e non a livello di pagina web. Se questa sarebbe una buona idea o no è una domanda completamente diversa.
I believe this is because then you can't salt and hash the password on the server side.
È vero che se utilizzi la crittografia simmetrica, non sarai in grado di proteggere correttamente la password sul server in quanto ne hai bisogno per verificare la risposta della sfida. Ecco perché utilizzi la crittografia asimmetrica per lo schema challenge-response. Ad esempio, sia SSH che la tua carta di credito utilizzano la crittografia asimmetrica. Con la crittografia asimmetrica, è possibile memorizzare la chiave pubblica sul server e l'utente può mantenere la sua chiave privata ... privata.
Leggi altre domande sui tag authentication passwords hash