2

I'm updating a login system. The password is sent to the server as SHA512(password + long_string). I want to switch this to something like SHA512(username + password) in the future.

By doing that I don't need to add "please login again" dialogs when the login system changes, and the passwords can be updated to the new format without users noticing.

Question: Would it hurt if I send both SHA512(password + long_string) and SHA512(username + password) when logging in? Assuming someone intercepts that data, would he be able to find the original password any quicker?

2

As the llama says, there is little point in pre-hashing the password on the client side: SSL protects you. Of course this assumes that you use SSL for all communications; if you do not, then you already have much bigger problems that you should tackle first.


If an attacker sees "SHA-512(password + long_string)" then the attacker can run an offline dictionary attacks on that password, i.e. trying potential password values until a match is found. Of course, this assumes that the attacker knows "long_string" but since both client and server know it, and it has not been entered by the human user, then one must assume that the "long_string" is either provided by the server prior to user authentication, or is hardcoded in the client code. Either way, it is unreasonable to assume that the attacker does not have it. The dictionary attack will run at a rhythm of several millions of tries per second, because, let's face it, a basic PC is really good at computing SHA-512.

To some extent, if "long_string" is really long (we are talking megabytes here), then the cost of hashing may become non-negligible and thus slow down the attacker. Such slowness is half (but only half) of what makes a good password hashing function. Note that cryptographic algorithms are subtle: "SHA-512(long_string + password)" would be much weaker, in that respect, than "SHA-512(password + long_string)" (if you do not see why, then don't touch that keyboard again). The second half of good password hashing is about deterring parallel attacks, which, in this case, would mean that each user has his own "long_string" value, distinct from those of the other users. The "long-string" then acts as a salt.

Your alternative, with "SHA-512(username + password)", fails at the slowness parts, and imperfectly ensures the non-parallel part (because user names are not unique worldwide, and are also reused when the user changes his password). Depending on how "long_string" is chosen in the original system, your proposal may weaken or strengthen the security.

The answer to the exact question is that if the attacker see both values then he can choose which one he will attack, and this can only help him. However, a more thorough answer is that:

  • You should send passwords only through a properly secured tunnel (SSL), at which point there is no good reason to hash the password on the client side; thanks to SSL, the client knows that it is sending the password to the right server, and only to that server. Simply send the password "as is".
  • If you plan to use the hashing as a storage mechanism on the server (i.e. the server does the hashing, not the client, and the result is stored in the server's database) then your new system may be slightly better than the previous, or slightly worse, but both are weak anyway. Go read that answer; it would be most unwise to design cryptographic systems with password until you understand it thoroughly (you do not need to agree -- Science without debate is no longer Science -- but at least you should understand the concepts).
  • Whoops. Didn't know pressing enter would submit my comment :( I'm hosting a really small service, so I'm not sure SSL is something I'm able to pull off (and part of the system I use doesn't even support SSL or any form of hashing). Right now passwords are sent in plain text, and a hash is stored without adding a salt. Changing both the way passwords are stored & the way they're sent isn't possible time-wise, so I thought this would be the best compromise. long_string is about 100 characters long and never changes, so changing it to SHA512(user + pass) is an improvement, right? – Size43 Jan 19 '14 at 19:19
  • 1
    SSL is free, have a look at www.startssl.com, they give free certs and are trusted by most browsers. – Lucas Kauffman Jan 19 '14 at 21:17
  • It's an improvement, but it still doesn't fix your problem. Just doing SHA512(password+user) isn't enough these days. Also using the username as salt is generally a bad idea, if several websites do this and they have their databases breached, then you can already start comparing. – Lucas Kauffman Jan 19 '14 at 21:19
  • 1
    I have implemented and run SSL servers on a 33 MHz ARM CPU and in less than 20 kB of RAM (yes, kilobytes). I simply don't believe that your service is "too small for SSL". – Tom Leek Jan 19 '14 at 22:23
  • Fair enough. SSL would be an option for the website. My server is not too small for SSL, but the project is used by so few people that it's probably not worth implementing a SSL library from scratch due to the lack of support from the language I'd have to write it in. The SHA512(password+user) is just so that I don't have to send the password in plain text. I'm scrypt-ing it with a random salt on the server-side. – Size43 Jan 20 '14 at 6:35
0

Just a quick question, why are you hashing your passwords before sending them to the server? You should be sending everything using SSL so that it does not matter if the password is hashed or not.

Also note that if you store your passwords using SHA512(username + password) or just SHA512(password+long) you are actually not using a secure hashing algorithm at all.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.