Secure Authentication without SSL

3
votes

I thought of an authentication system without SSL that seems reasonably secure. Am I overlooking something important?

  1. User hits the login page
  2. Server generates a salt for transmission (t-salt) and stores it in the session
  3. Server sends the t-salt to the user as part of the login page that loads
  4. User types in their username and password and clicks submit
  5. Browser MD5 encrypts their password along with the t-salt
  6. Browser sends username and MD5 (password + t-salt) to the server
  7. Server retrieves password from database using username (*) Note below
  8. Server MD5 encrypts password retrieved from step 7 along with the t-salt that was stored in the session in step 2
  9. Server compares both of the MD5s from step 6 and step 8
  10. If they are identical, the login is successfully authenticated
  11. The server removes the t-salt from the session (added in step 2) to prevent potential replay attacks

* Note that the password retrieved in step 7 cannot be 1-way encrypted (as is common practice) in order for step 8 to work. But 2-way encryption systems can still be used to secure passwords at the database level. (Hey, that comes with the side benefit of allowing a more user friendly password recovery process.)

Aside from my note immediately above, what are the strengths and weaknesses of this scheme?

6
phpmysqldatabasesecurity
What's wrong with just using SSL? - ceejayoz
From what I see, there are no strengths and a lot of weaknesses. This seems like a terrible idea. Storing your passwords in plain text would be more secure than that. You're better off just going with a normal authentication scheme: send a plain text password, salt and hash it on the server side and compare against the stored password hash, or use SSL, or both. - netcoder
ceejayoz: What's wrong with using SSL is that it is another component to add to a system. A PHP library that can be dropped into a project would be simpler. netcoder: Storing passwords in plain text is not more secure than any alternative to storing passwords in plain text, and that can probably be proven mathematically. :) I'm not interested in industry dogma here as I am trying to learn and explore new ideas. I know academically correct people don't find this valuable, but I have a strong conviction that there may be a clever solution to this, perhaps more involved than what I thought of. - OCDev
If you really want to get feedback on the strength/weakness of this protocol, ask at security.stackexchange.com, I suppose. But in the end, it fails to suit its purpose: the server cannot be sure if he is talking to the "right" client or a proxy, and the client cannot be sure if the server is trustworthy or not. SSL actually relies on the server showing a certificate, signed by an authority that the client already trusts. - giraff

6 Answers

10
votes

This'd be wide-open to man-in-the-middle attacks. Nothing would stop an attacker from sniffing the link and getting the salt as it goes from server->client or the hashed password as it goes from client->server, and replaying either.

Invalidating and generating a new salt after each attempt would prevent simple replays, but then it comes down to a race condition - can the attack submit their login attempt before the user? Even then, since the attacker's sitting in the middle, they could presumably interrupt the user's link, capture the salted password, and submit it themselves and capture the session.

8
votes

You send the t-salt and the hashing algorythm. It wouldn't take long to calculate the password inside the hash.

You should reconsider SSL in my opinion.

2
votes

While I think that your intentions are good, the fact of the matter is that there really is no security offered at all in your approach. As others have pointed out, any reasonably competent hacker will be able to intercept data going over the wire and execute a replay attack. That is not to mention the fact that any data going over the wire will be unencrypted, which exposes your users' potentially sensitive information to anyone.

2
votes

The problem with this is that you're making the assumption that SSL is purely about encryption. Take a look at SSL is not about encryption. On this basis, your scheme falls apart at step 1 because you have no assurance that when the login page is loaded it has actually come from the site you think it has and that it hasn't been tampered with.

There are many precedents of this happening, the Tunisian government harvesting usernames and passwords is a good one and you'd be wide open to this style of attack as your login page could be altered before it even hits the browser.

Then of course you have the Firesheep problem in that your auth persistence (which I assume you do via cookies), is going backwards and forwards across an unencrypted network. It doesn't matter what you encrypt inside these cookies, if someone is able to grab it and reissue a request (very easily done at a public wifi hotspot), then you've got a session hijacking problem.

Then there's also the known weaknesses in MD5 but even using a more secure hashing algorithm won't save you from the other problems described above. Spend a tiny bit of money, do some minimal configuration and make SSL part of your login process. Refer to the OWASP Top 10 on Insufficient Transport Layer Security for more info.

Finally, SSL is not intended to be a panacea; it won't protect you from key loggers, it won't protect you from having your database breached and it won't protect you from someone whacking your end users over the head with a wrench until they disclose their password. But it's not meant to do any of these things, it's simply intended to be one more layer of defence - albeit an essential one - which is part of a broader security strategy.

1
votes

One thing to think about is that SSL doesn't just provide confidentiality and integrity protection to the overall data stream (via encryption) it also provides a level of validation of the identity of the server.

In your example there's no way (that I can see) for the client to validate that they are speaking to the real server before providing their password, as such a DNS spoofing attack or some other MITM attack would be effective.

Also as mentioned, it would be possible to brute-force a users password quite easily as the attacker can intercept the salt going from server-->client and then the hashed password coming back. MD5 being a fast hash algorithm it would likely be quite an effective attack against standard user passwords.

0
votes

The data transmitted while authenticated won't be secure, and implementing your own schemes is usually a pretty bad idea.