Non-SSL salted password logins

[davej]

So the user loads the login page and the server starts a session and provides a hidden datetime value. The clients Javascript extracts the datetime value, validates it as being reasonable, and uses it to salt the user's password and hashes it. The hashed password and userid is then sent to the server.

 

Are there any holes in this concept?

[justsomeguy]

If you're not hashing on the server then an attacker does not need to know the user's password, all they need to know is the user's password hash, which they can get since the traffic is not encrypted.

[davej]

Well, this gets to be somewhat of a "chicken-and-the-egg" situation, but let's presume for now that a registration process has previously given the server a username and a hashed password to put into the database.

 

Now the client transmits a double-hashed password. The first hash recreates what the server has stored in the database. The second hash uses the datetime salt.

 

The server can retrieve the hash from the database and hash it again using the datetime and then compare the result to the received value.

 

Since the datetime will never be the same again it is a "one-time-use" situation.

Edited February 14, 2014 by davej

[justsomeguy]

That doesn't matter. If the browser sends the server a value that the server does not hash, then anyone else can send that same value to the server. Your idea is basically the same as if you saved plain text passwords in the database and then submit a plain text password along with some other token. If someone else submits the same data to the server then it will let them log in, assuming the token is valid. You are talking about sending the server a value that it does not hash, which might as well be a plain text password. The reason password security works is because the server gets the plain text password, hashes it, and compares that with the database. The database hash will only match if the password is the same. With your scheme that gets bypassed, with your scheme the server does not transform the submitted data. It doesn't matter if it hashes what is already in the database, if it doesn't change the submitted data then it's useless. The term for that is a password replacement, the attacker doesn't need the actual password, just what gets submitted to the server. The thing with the token, in your case a timestamp, is the same issue that you brought up in the thread about session hijacking. If there is a program listening to traffic then it can get those values and submit them at virtually the exact same time as the user, and they're in.

 

If you are really dead-set on avoiding SSL at any cost, then use a two-step login process. First they enter their username, then they get redirected to a different form for their password. When you display the form you look up their username to make sure it's valid at least, and generate a random token that you save in the database and also send to the client. The client hashes the password with that token as the salt. You submit the form, get the same token from the database, and hash it the same way on the server to check. But there are problems with that technique also, one of which is that you cannot save the passwords as hashed in the database, you need to save them encrypted so that you can decrypt them to hash with the random token. So then you lose the security benefits of having passwords that are strongly hashed in your database. If someone got your database and your code, then they also got every password. You may be able to think of other workarounds for various issues, but the bottom line is that there is no substitute for strong hashing with client-to-server encryption. You will not be able to create something that is as secure as that, anything else is going to be less secure, even if only a little.

[davej]

Ok, I wasn't including the database security aspect. Yes, the received password should be salted and hashed by the server before storage in the database. I should not gloss over that necessity.

 

edit--

 

I think it will still work if an individual salt is not considered a critical secret. Revealing a salt isn't going to do them much good unless they actually analyze the Javascript code and then make a brute-force attempt to crack the password offline.

 

If the user begins a login process the client could supply the username. If the username is valid then the server responds by sending the retrieved database salt and also a new salt. The client then hashes the raw password with the database salt and then hashes it again with the new salt. The double-hashed one-time-use result is then sent openly to the server.

Edited February 15, 2014 by davej

[thescientist]

the received password should be salted and hashed by the server before storage in the database. I should not gloss over that necessity.

 

...

 

The client then hashes the password with the database salt and then hashes it again with the new salt. Then the double-hashed result is then sent openly to the server.

How is it expected that the now double hashed password with the new salt is going to match what's in the database though?

[davej]

It won't but the database value can be pulled out and rehashed with the new salt. The result should then be equal to the double-hashed password.

 

I don't know at what point it may make more sense to look at encryption rather than hashing.

 

The idea of openly sending the double-hashed password that someone could take and crack offline could be greatly improved if the double-hashed password was sent as a random member of perhaps 16 or 32 bogus hashes. The server can easily test an array of 32 hashes per login attempt.

 

(I should also re-emphasize that this is still INFERIOR to SSL)

Edited February 17, 2014 by davej