Se la tua applicazione desktop ha qualcosa a che fare con "i fili", suppongo che tu preveda la seguente configurazione: l'applicazione è quella che richiede la password dell'utente, ma la verifica effettiva della password viene eseguita altrove, in un server di autenticazione remota . Questo sarebbe tipico della rete basata su Windows con Active Directory , o reti basate su Unix con Pagine gialle o un server LDAP per le password.
Non vuoi mai inviare una password, hash o meno, "in testo normale sui fili". Infatti, in un semplice processo di login, l'applicazione invia qualcosa al server, e quel qualcosa è sufficiente per ottenere l'accesso. Un intercettatore potrebbe semplicemente registrare questo qualcosa e riprodurlo più tardi. Non importa se questo qualcosa è una sequenza di lettere che ha senso per un essere umano, o una sequenza di altri byte che può o non può essere un valore hash. Finché ciò che il client invia è sufficiente per sbloccare le cose, allora l'invio deve essere protetto dagli sguardi indiscreti degli intercettatori, e ciò richiede SSL / TLS , che garantisce la riservatezza dei dati.
Un altro punto importante è che gli attaccanti possono essere attivi . Un attaccante attivo è colui che ha dirottato un router tra due macchine e può modificare i dati in transito a proprio piacimento. Nello scenario di un'applicazione desktop che comunica con un server di autenticazione, l'utente malintenzionato attivo può modificare la risposta dal server di autenticazione da un "No" grave a un "Sì" caldo, simulando così un accesso riuscito anche se la password è errata. Anche in questo caso, è necessaria protezione, questa volta per mantenere integrità ; Anche SSL / TLS lo fa.
Quindi ci sono due buoni motivi per usare SSL o un protocollo con caratteristiche simili: il client ha una certa garanzia che dialoga con il server giusto, i dati sono crittografati e c'è un MAC che protegge dalle alterazioni. Se viene utilizzato un tale protocollo, ALLORA la password può essere inviata "così com'è" nel tunnel (protetto) e non vi è alcun limite nell'hashing o nella crittografia ulteriore.
Si noti che esistono alcuni protocolli di autenticazione (ad es. CRAM-MD5 ) che utilizzano un trattamento più complesso, incluso l'hashing dal lato del cliente; lo fanno perché presumono che non ci sia un tunnel simile a SSL. Usando una sfida dal server, hashed insieme alla password sul client, proteggono dagli attacchi di replay . Tuttavia, sono ancora deboli contro gli attaccanti attivi; inoltre, fanno in modo che gli intercettatori imparino i valori hash calcolati su password, il che è sufficiente per eseguire attacchi dizionario offline (l'intercettatore "cerca" potenziali password sulle proprie macchine, limitate solo dal numero di PC che può radunare). Per questi motivi, un tunnel protetto come SSL è considerato una soluzione molto migliore. Come sottoprodotto, il tunnel simile a SSL rende irrilevante l'hashing client-side. Ciò rende molto più semplice l'attività dell'applicazione client. In realtà, rende tale compito molto più semplice che l''applicazione' del client può essere un semplice modulo HTML nella pagina Web.