Secure transmission for desktop applications

Question

Suppose I have a desktop application that does password hashing for login authentication.

Is the password normally hashed before it travels to the wires or does it travel to the wires first in plain text and it is hashed after?

Answer 1

It depends on the specific implementation of the desktop application. If the developers were being reasonably security conscious, they wouldn't send the password over the network in clear text. But it is entirely possible that the developers of the application would have sent the password in clear text.

If you want to find out which approach your particular application is using, you would generally need to use something like Wireshark to inspect the network traffic during the login process. That will show you whether any particular application is sending the password in clear text over the network.

Answer 2

If your desktop application has anything to do with "the wires" then I suppose that you envision the following setup: the application is the one which requests the user password, but the actual verification of the password is done elsewhere, in a remote authentication server. This would be typical of Windows-based network with Active Directory, or Unix-based networks with Yellow Pages or a LDAP server for passwords.

You never want to send a password, hashed or not, "in plain text over the wires". Indeed, in a simple login process, the application sends something to the server, and that something is enough to be granted access. An eavesdropper could simply record this something and replay it later on. It does not matter whether this something is a sequence of letters which makes sense to a human being, or a sequence of other bytes which may or may not be a hash value. As long as what the client sends is sufficient to unlock things, then the sending must be protected from the prying eyes of eavesdroppers, and this calls for SSL/TLS, which ensures confidentiality of data.

Another important point is that attackers can be active. An active attacker is one who has hijacked a router between two machines, and can alter the data in transit at will. In your scenario of a desktop application talking to an authentication server, the active attacker could change the response from the authentication server from a severe "No" to a warm "Yes", thus simulating a successful login even though the password is wrong. There again, protection is needed, this time for maintaining integrity; SSL/TLS does that, too.

So there are two good reasons to use SSL or a protocol with similar characteristics: the client has some guarantee that it talks to the right server, the data is encrypted, and there is a MAC which protects against alterations. IF such a protocol is used, THEN the password can be sent "as is" in the (protected) tunnel and there is little point in hashing or encrypting it any further.

Note that there are some authentication protocols (e.g. CRAM-MD5) which use more complex treatment, including hashing on the client side; they do that because they assume that there is no SSL-like tunnel. By using a challenge from the server, hashed together with the password on the client, they protect against replay attacks. However, they are still weak against active attackers; also, they let eavesdroppers learn hash values computed over passwords, which is enough to run offline dictionary attacks (the eavesdropper "tries" potential passwords on his own machines, limited only by the number of PC he can muster). For these reasons, a protected tunnel like SSL is deemed a much better solution. As a byproduct, the SSL-like tunnel makes client-side hashing irrelevant. This makes the client application task much easier. Actually, it makes that task so much easier that the client "application" can be a simple HTML form in Web page.

Answer 3

The most common practice is for the client to send the server the plaintext of the password (preferably while using SSL) and the server then rehashes it to compare to the database. The point of hashing is to prevent the exposure of the passwords by accessing the authentication database.