Public Safety Announcement: On the subject of password security

[Astrohacker]

Consider using bcrypt for hashing passwords. bcrypt is designed to be difficult to compute, with tunable difficulty.

Edit: Come to think of it, you could always use the tunable difficulty method of bitcoin. Use a nonce rather than a salt, and require that the hash be below a certain number.

[bcearl]

Besides, MtGox was "hacked" by the only side nerdness can't do nothing about: the HUMAN factor. Wouldn't make a difference other than slow the attacker a bit to use SHA-512 or any other hashing/crypting flavor. As obvious M'Tux had no clue his db was compromised, so the attacker actually had all the time in the World to do whatever he needed to do.

It's not that nobody thought of that, it's that there are problems that cannot be solved. That's why the whole concept of MtGox was flawed.

The whole point of bitcoin is that you don't need websites doing such jobs like money transfer any more. But what did they come up with?  A typical site with the same crap we know from banking sites, paypal etc.

[Gareth Nelson]

Please, service providers...  Use the best possible solution available!

If you can use multiple SHA512 hashes with each different unique salts form different sections of passwords... do it! If you can run that same thing 5 passes... do it!

Don't just go with MD5 + usalt because "no-one will ever get the database". Always prepare for the worst case scenario. HAve graceful hash updates! If a better hashing method becomes available, make users reset their password! (Or have it be done automatically on log in using submitted password for 30 days, and after that time, require reset.)

Thanks for listening, do shout at me if you think this is stupid advice!

You're doing it wrong - making people change their passwords every 30 days results in them running out of quality passwords OR them writing their password down.

Multiple hashes? If you want to be paranoid that's also the wrong way to go about things, you should use a system like bcrypt and make sure it's slow enough that GPU bruteforce is a no-go.

Partition the database too, don't have one big MySQL database with full perms which every part of the site has access to - one exploit on any part and it's game over. Limit it tightly, VERY tightly.

Even the human factor can be mitigated - don't give access to EVERYTHING to EVERY employee, restrict things tightly.

Use whitelists, not blacklists.

[Gareth Nelson]

Consider using bcrypt for hashing passwords. bcrypt is designed to be difficult to compute, with tunable difficulty.

Edit: Come to think of it, you could always use the tunable difficulty method of bitcoin. Use a nonce rather than a salt, and require that the hash be below a certain number.

Every time the difficulty of bitcoin increases it means there's more hashing power out there that could be redirected.
Truly paranoid types may want to use that as a sign that it's time to hash all existing passwords again (hash the hash and keep a count of how many hash operations).

[M4v3R]

If you can use multiple SHA512 hashes with each different unique salts form different sections of passwords... do it! If you can run that same thing 5 passes... do it!

We, at BitMarket.eu, had this from the very beginning. It's just a few lines of code people. And the benefit in security is huge.

Do the community a favor.  Provide the "few lines of code" here for everyone to be able to use.

Sure, here you go:

Code:

	function getPasswordHash($password, $login, $rounds = 25) {
		$base = $password . ":" . $login . ":" . $GLOBALS['config']->secret_salt;
		$buffer = "";
		for ($i = 0; $i < strlen($login) * $rounds; $i++) {
			$buffer .= hash("sha512", $base . ":" . $buffer);
		}
		for ($i = 0; $i < strlen($password) * $rounds; $i++) {
			$buffer .= hash("sha512", $buffer);
		}
		return hash("sha512", $buffer);
	}

User's login is also the random salt in this case. As an added security, we add secret salt (from some config file on the web server). $rounds is just a multiplier for how much processing should be done. At 25, generating one hash can take (depending on password and login length) from 0.1s to 1s. Which essentially makes bruteforcing impossible.

This, of course, could be done in a ton of different ways. One could also use bcrypt. I've decided to use my own routine, because it's not widespread and programming hash-breaker to target this specific routine would take some time - time that is needed to react if something bad happens.

[bitsalame]

Can you PLEASE cut this bull about attempting to blame users?!
Use a 30 char long pass, alpha upper+lower+numeric+symbols... in the day you format your computer and if you forget to backup the text file with it, please, kiss your account goodbye. And don't even try to access wherever you use it from outside home, as obviously you've no clue whatsoever that password is.

Nerds! People have a life! Good security is passive, is simply there, BAD security is anything that has to nag you to be secure.

Besides, MtGox was "hacked" by the only side nerdness can't do nothing about: the HUMAN factor. Wouldn't make a difference other than slow the attacker a bit to use SHA-512 or any other hashing/crypting flavor. As obvious M'Tux had no clue his db was compromised, so the attacker actually had all the time in the World to do whatever he needed to do.

Actually, you are wishing wonderland.
In the real world there is generally a trade-off of practicality vs. security.
The more secure is a design the more annoying it is to use it.
This is almost a philosophical inevitability:

If it is easy for you to get in, the easier for an attacker.
The harder for the attacker to get in, the harder for you to get in.
At the end all security measures are in fact economical deterrence methods.
The only solution to secure a system is adding layers of security and making it cost inefficient for the attacker.

See the airports? How annoying is the security?
Secure passwords? annoying as hell, huh?
Bullet proof vests? Have you ever wore one? They are heavy and uncomfortable like shit. The more calibers it can take, the heavier it gets.
Biometrics seem to escape the rule right? Seems to be simple enough and secure, well, let me pop the bubble: actually they are not as secure as they want us to believe. Actually biometric systems are very easy to fool.

If you are wishing STRONG security being EASY TO USE, you are wishing a chimera.
The weakest link in a secure system is always the human being, and this fact is known by all security experts (so called nerds, as you claim).
If the human is dumb enough to write down his password, or set it up as 1234, there isn't any algorithm in the world that will save him from his own stupidity.

[BCEmporium]

Nerds != "Security Experts"

Nerds == Nerds && some == paranoia

There's no linearity between "as easy to you as easy to the hacker", actually I would forget a pwd as 12345 taken I never used it. So if I try to login in the future with such I would face a hard time to remember.
At some point you've to access your info, you may use a pwd manager, but that thing have to have its database somewhere and probably a master password that opens it all. Someone getting his hands to it not only gets all of your pwds as also you can't do nothing about it as you yourself have no clue on what those pwds are.

The biggest flaw on nerds and security is exactly on how much they tend to miss the human spot, believing machines can stand on their own or if they're annoying it improves security.
Ultimately the most secure computer is one that is switched off...

[Rob P.]

Sure, here you go:

Code:

	function getPasswordHash($password, $login, $rounds = 25) {
		$base = $password . ":" . $login . ":" . $GLOBALS['config']->secret_salt;
		$buffer = "";
		for ($i = 0; $i < strlen($login) * $rounds; $i++) {
			$buffer .= hash("sha512", $base . ":" . $buffer);
		}
		for ($i = 0; $i < strlen($password) * $rounds; $i++) {
			$buffer .= hash("sha512", $buffer);
		}
		return hash("sha512", $buffer);
	}

Hey thanks!  Looks good, thinking of using it.

[gmaxwell]

User's login is also the random salt in this case. As an added security, we add secret salt (from some config file on the web server). $rounds is just a multiplier for how much processing should be done. At 25, generating one hash can take (depending on password and login length) from 0.1s to 1s. Which essentially makes bruteforcing impossible.

At 25 rounds of your function you are less secure, computationally wise, than the FreeBSD crypt_md5 used by MTGOX for most of the passwords (which uses 1000 rounds).  Yours is only so terribly slow because your implementation is slow— passing through the interpreted language for every round.

Using the not super well optimized SHA-512 code in OpenSSL gives me 1,595,914 iterations of the whole algorithm per second on a single core of some 2.6 GHz i7.
(On 64bit systems SHA-512 is faster than SHA-256, and our miners that do most of 2x SHA-256 get 1MH/Core/GHz, so this sounds perfectly reasonable)

You're also failing to use per-user random salt, which means that an attacker with multiple versions of the user's password field (e.g. captured over time) will get an N-fold speedup from being able to hash once and compare multiple times.

So, in short, you've screwed up. Your failure to use standard functions left your security worse off than it would be using the decade old crypt_md5.

Unless you're a cryptographer you shouldn't be writing your own cryptographic functions.

[M4v3R]

It's not 25 rounds. It's 25 * login length + 25 * password length + 1 iterations. So it's basically few hundrets. Did you measure this code or just 25 rounds of SHA-512?
I stand corrected on the random salt though - it shouldn't derive from username alone.

[gmaxwell]

It's not 25 rounds. It's 25 * login length + 25 * password length + 1 iterations. So it's basically few hundrets. Did you measure this code or just 25 rounds of SHA-512?
I stand corrected on the random salt though - it shouldn't derive from username alone.

Indeed, I missed the strlen()*  bit.  So 401 rounds for 8,8... Which is actually somewhat slower than crypt_md5 is for me. Hurray.   Sorry for being a bit quick to criticize on that point.

But yea, random salt is important.  It would be more accurate to call your "secret_salt" a "password key" or something like that, calling it salt promotes the misunderstanding of what salt is that results in people not using random salt.

[M4v3R]

About the naming - you are probably right. Calling this a "secret key" would be more appropriate.
I'll think about adding the extra salt from other table columns. Even adding registration time to this mix should do the trick I think .

[Bunghole]

The major brokerage firm Schwab limits their passwords to 8 chars, letters and numbers only - and with no second-factor authentication like SMS, email, or a code fob.  WTF.

Oh, and they don't even let you know.  For months I had nice long secure password, thinking I was safe.  One time, I accidentally forgot to type the whole thing, and I got in anyway.  I was like, what the hell is going on?  I dug into their help screens and found the 8-char limitation.

My guess is that they need to use an 8-char password to be interoperable with some other system that uses shitty 8-char passwords.

Update: I just checked and they finally added 2-factor authentication.  Regardless, they had 8-char passwords and no second auth for a couple years.

[BCEmporium]

Regardless, they had 8-char passwords and no second auth for a couple years.

...and never got hacked... go figure!
I keep saying the major breach is humans, machines have ways to be secure and they don't do more than what they're programmed to do, people don't.

[BCEmporium]

I know you all will jump into a bashing... typical! You believe to be "d4 h4x0r" when you get paranoiac. But I would advise AGAINST M3v4R code.

Amazed? While you've your login system entertaining your system resources rolling SHA hashes around, you expose yourself more to DDoS and overflow attacks. Like said; the biggest issue with paranoia is that it makes you to try so hard to cover a hole that you'll end up opening a crater elsewhere.
To not mention that under a DDoS with that slow login method, your legit users will contribute to the DDoS by hitting F5 like crazy.

[M4v3R]

I know you all will jump into a bashing... typical! You believe to be "d4 h4x0r" when you get paranoiac. But I would advise AGAINST M3v4R code.

Amazed? While you've your login system entertaining your system resources rolling SHA hashes around, you expose yourself more to DDoS and overflow attacks. Like said; the biggest issue with paranoia is that it makes you to try so hard to cover a hole that you'll end up opening a crater elsewhere.
To not mention that under a DDoS with that slow login method, your legit users will contribute to the DDoS by hitting F5 like crazy.

Not exactly. You would get banned after a couple of tries (the script would entirely skip the login routine), so it wouldn't have effect on our system. And in normal operation it doesn't have impact on the site either. It would be if we had at least people logging in every minute, which I don't see happening any time soon. And even then getting a better hardware (more CPU cores) is not a problem.

[phillipsjk]

It doesn't really matter how long the Hash function takes (though slower is better). A sufficiently motivated attacker can simply buy enough CPU power to negate the constant extra time each hash attempt takes.

What is important is the amount of password entropy. It is getting to the point where anything with less than 64bits (1.844674407×10¹⁹ possibilities) of entropy is insecure. The good news it that it is believed it is nearly impossible to brute force a password with 128 bits of entropy: even counting from 1 to 3.402823669×10³⁸ is expected to take more energy than is available in the known universe _{[Citation Needed]} .

I commonly use passwords with about 60 bits of entropy.  As I have said, such passwords should now be considered insecure. The only way to remember unique, secure passwords for all of your websites is to write then down, use a keyring or both. Not writing something down a secure password should be reserved for one or two high value passwords.

I have often seen suggestions to use song lyrics or portions of books. Consider this: I think in the history of mankind, fewer than 1.844674407×10¹⁹ paragraphs have been written. If your password has ever been published, assume Google or well-funded governments have it in their database. That includes examples of "secure" passwords and known UUID's

I am planning on moving to passwords with 96 bits of entropy. I will have to update my chart to show passwords of that strength. For high-value passphrases, I have been using 128 bits of entropy for over a year. Keep in mind some overkill may be justified if you feel the Hash function or encryption algorithm may fall to non-brute-force attacks.

PS: For the paranoid; if you ever type the wrong password into the wrong site, you should got back and change the password on the site it really belonged to. Alternatively, once you have all you passwords written down, change them from time to time on the assumption they may be compromised.

[BCEmporium]

@M4v3R

Hope you hadn't forgot to input a maxpwd/user len or your may suffer bot-registering attacks like:

User: mytrolololololol...lololouser
Pwd: mytrolololololol...lololopwd

Making your server look like a mining rig.

I've no doubt your system safe, still a less safer and more operational solution would be as good as long as the database is well secured.

[Man From The Future]

Please, service providers...  Use the best possible solution available!

If you can use multiple SHA512 hashes with each different unique salts form different sections of passwords... do it! If you can run that same thing 5 passes... do it!

Don't just go with MD5 + usalt because "no-one will ever get the database". Always prepare for the worst case scenario. HAve graceful hash updates! If a better hashing method becomes available, make users reset their password! (Or have it be done automatically on log in using submitted password for 30 days, and after that time, require reset.)

Thanks for listening, do shout at me if you think this is stupid advice!

You're doing it wrong - making people change their passwords every 30 days results in them running out of quality passwords OR them writing their password down.

Multiple hashes? If you want to be paranoid that's also the wrong way to go about things, you should use a system like bcrypt and make sure it's slow enough that GPU bruteforce is a no-go.

Partition the database too, don't have one big MySQL database with full perms which every part of the site has access to - one exploit on any part and it's game over. Limit it tightly, VERY tightly.

Even the human factor can be mitigated - don't give access to EVERYTHING to EVERY employee, restrict things tightly.

Use whitelists, not blacklists.

You're right, I am doing it wrong - I've only attempted to do it better than large companies do it - which turns out to be completely rubbishly!

[M4v3R]

@M4v3R

Hope you hadn't forgot to input a maxpwd/user len or your may suffer bot-registering attacks like:

User: mytrolololololol...lololouser
Pwd: mytrolololololol...lololopwd

Making your server look like a mining rig.

I've no doubt your system safe, still a less safer and more operational solution would be as good as long as the database is well secured.

Yeah, I have a limit to 25 chars per username and 30 chars per password. I agree that access to db should be guarded better than anything, but everything can fail in the end, so having secure password storage is a must these days.