Hash · Programming

Anyone have a sha512 JS module for passing secure hashed password instead of plain text?

Tyler Balaban

April 25th, 2014

Working on a verification setup and don't want to post a password unless it's been encrypted. I was wondering if any of you know of a standalone JS module for sha512 hashing. Haven't been able to find anything that works properly using Google.

Brian Ledger Data Scientist at Coherent Path

April 25th, 2014

cryptoJS is your one stop shop

Marcus Matos Software Development & Information Technology Professional

April 25th, 2014

Oops - FD ate the first part of my post. Here it is again:

"If the average joe blow logs in with password: bob  (an example of course not actually) and the captured password is a ridiculously long hash, at least the user is more protected as their password: bob that they use for every site is encrypted."

Except you've created an extra security issue:
1.) The attacker has the hash and as you mentioned earlier you planned to salt "server side". So, you have an unsalted hash that I can just run against a rainbow table and guess what? Now I have the user's password.
2.) Even if you hash + salt client side, you are creating a dependency on JavaScript being enabled and proper client side implementation.
3.) Even if your client side implementation is perfect, you have not eliminated the risk of what happens if the user's hashed password is captured. Since the hash is used for authentication - I don't need the password - I just need the hash to authenticate to this system.
4.) Even if my target isn't this system, but actually the user's password, as I mentioned your implementation exposes the necessary information to perform a rainbow table attack. While salts are not considered information that you need to go out of your way to protect, you don't exactly want to deliver it in to your attacker's hands either.

In reference to SSLStrip - if you're being attacked by someone with the means to intercept the web traffic necessary to carry out this attack, I guarantee your implementation won't protect against them. In fact, you're giving them an additional attack angle that they could do offline.

Summary: If you want to protect against SSLStrip, make your site 100% SSL only and you're done. Avoid protecting against one angle of attack by exposing others.

Diego Basch Holder of Self-Referential Title

April 25th, 2014

That's why you enforce a minimum password length. A sha512 hash of bob gives you a false sense of security. Your code is available in your js, so your attacker knows your algorithm. It would be more secure to enforce a 20-character password length, and encourage users to type in a phrase instead of a password. You can detect and reject obvious patterns if you'd like, but you can't protect all users from a skilled password breaker. Also, it's not your job to protect your user against their password reuse. That's an internet-wide problem. A user who reuses passwords might as well have a keylogger installed, in which case 2FA is your only safeguard. The point of 2FA is that if the entire chain is compromised and someone tries to log in as your user with just the password, you know that something's wrong and can alert the user. To sum it up: read about best practices and don't reinvent anything. Extremely smart people have been thinking about this problem for decades, and there is a state-of-the-art set of practices that depends heavily on your threat model and attacker motivations.

Marcus Matos Software Development & Information Technology Professional

April 25th, 2014

Tyler,

If you're hashing client side, the salt is dealt with client side. I don't think you understand that when you hash client side, the transmitted hash effectively becomes the password and therefore is susceptible to the very same concerns you have about SSL being stripped away (which is really only possible with a MITM attack). 

I urge you to read up on client side hashing and gain some understanding of why it's not considered a good practice and is very rarely done. Good luck! 

Marcus Matos Software Development & Information Technology Professional

April 25th, 2014

Tyler, 

I'd argue that if you don't trust SSL, then hashing won't make a difference. If you have transmit a hash for authentication purposes, you should treat that hash the same way you'd treat a sensitive password. Additionally, by hashing client side you're locking yourself in to a situation where 1.) You cannot easily change out your hashing function without both client and server updates and 2.) you'd effectively need to expose the user's salt (and you are salting each user password separately, right?) 

Most issues are around a lack of knowledge of proper implementation and by trying to add another layer of complexity to your process you are more than likely actually reducing the level of protection. 

Question for you: how will you prevent the plaintext password from being sent to the server if the user turns Javascript off?

Anyway, a Google search for "Javascript SHA 512" had several potential results, including http://caligatio.github.io/jsSHA/. I recommend you tread carefully.

Marcus Matos Software Development & Information Technology Professional

April 25th, 2014

Tyler, 

Why reinvent the wheel? Can you just use https / SSL to accomplish what you are looking to do? 

Diego Basch Holder of Self-Referential Title

April 25th, 2014

If there's a MITM attack, all bets are off. Either someone stole your certificate and is pretending to be you, or SSL is broken. No matter the case, encrypting the password client-side doesn't prevent anything at all: the attacker can use the encrypted password to log in as the user. See this answer: http://stackoverflow.com/questions/14907581/ssl-and-man-in-the-middle-misunderstanding Also, you want HSTS http://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security and CRSF protection on login.

Sean Power Co-founder at Repable

April 25th, 2014

This is the kind of question that's perfect for StackExchange.  I doubt you'll get many answers here.

Ken Woodruff Software Architect

April 25th, 2014

There were a few reasons for this, but the most salient was protection against bad configurations. It's all well and good to say "we'll only ever use https", but that's making an assumption that "we will never, ever accidentally configure something to allow http", which, in practice, happens all the time, even in well run organizations. Add in the complexity of load balancers and reverse proxies doing the SSL termination and even in a properly configured environment there are risks.

Diego Basch Holder of Self-Referential Title

April 25th, 2014

Then you should focus on process. Your system should be designed to never, EVER run without SSL. You can have many safeguards, one of which is HSTS. Security is a process, not software.