Dipende dalla specifica implementazione dell'applicazione desktop. Se gli sviluppatori fossero ragionevolmente attenti alla sicurezza, non invierebbero la password attraverso la rete in testo chiaro. Ma è del tutto possibile che gli sviluppatori dell'applicazione avrebbero inviato la password in chiaro.
Se vuoi scoprire quale approccio usi la tua particolare applicazione, generalmente dovresti usare qualcosa come Wireshark per ispezionare il traffico di rete durante la procedura di accesso. Questo ti mostrerà se una particolare applicazione sta inviando la password in chiaro tramite la rete.
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.
La pratica più comune è che il client invii al server il testo in chiaro della password (preferibilmente durante l'utilizzo di SSL) e il server quindi lo rihash per confrontarlo con il database. Il punto di hashing è impedire l'esposizione delle password accedendo al database di autenticazione.