The salt has real value - it prevents rainbow table attacks. Without it, one could crack many passwords in a fraction of a second.
Too bad MtGox stored the salt in the password field, next to the password.
Topic: Public Safety Announcement: On the subject of password security - page 2. (Read 5882 times)
Too bad MtGox stored the salt in the password field, next to the password.
Actually is ironic that a lot of BTC users were hacked using a technique mostly developed to actually mine BTC; GPU hashing.
This.
99 % of what's being said about password hashes here seems to be inaccurate or flat out wrong.
MD5 isn't nearly as weak as people seem to think. A lot of is because articles often say things like "a 6-character alphanumeric MD5 can be cracked in a second these days". While that may be true, they often fail to mention that the required time grows exponentially with each character. A 12-character one takes 56800235584 times longer. If the "in a second" part is correct, that's 1801 years. Add a special character in there and you are looking at 540360087662636962890625 combos. At 10 terahashes per second you will be through them all in some 600000 years. And that's just a simple MD5. Unix crypt does it somewhere around 1000 times over with some added flavors.
The purpose of a salt also seems to be misunderstood. It's really only there so that each password needs to be tested separately. Having something 'secret' added to the string doesn't hurt, but it doesn't add any value to cryptographic strength. It's really just a plaintext password hidden in code.
99 % of what's being said about password hashes here seems to be inaccurate or flat out wrong.
MD5 isn't nearly as weak as people seem to think. A lot of is because articles often say things like "a 6-character alphanumeric MD5 can be cracked in a second these days". While that may be true, they often fail to mention that the required time grows exponentially with each character. A 12-character one takes 56800235584 times longer. If the "in a second" part is correct, that's 1801 years. Add a special character in there and you are looking at 540360087662636962890625 combos. At 10 terahashes per second you will be through them all in some 600000 years. And that's just a simple MD5. Unix crypt does it somewhere around 1000 times over with some added flavors.
The purpose of a salt also seems to be misunderstood. It's really only there so that each password needs to be tested separately. Having something 'secret' added to the string doesn't hurt, but it doesn't add any value to cryptographic strength. It's really just a plaintext password hidden in code.
Take notice that not many people use 12 character passwords. Heck, most of the hacked passwords I saw was 6-8 character long. Also, if you take GPU hashing into account, the times needed to crack them drops significantly.
The salt has real value - it prevents rainbow table attacks. Without it, one could crack many passwords in a fraction of a second.
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
Using just plain song lyrics would be really, really bad advice.
Deciding on an algorithm only known to oneself and using song lyrics as a source of entropy is a good idea.
Unless you're a cryptographer you shouldn't be writing your own cryptographic functions.
This.
99 % of what's being said about password hashes here seems to be inaccurate or flat out wrong.
MD5 isn't nearly as weak as people seem to think. A lot of is because articles often say things like "a 6-character alphanumeric MD5 can be cracked in a second these days". While that may be true, they often fail to mention that the required time grows exponentially with each character. A 12-character one takes 56800235584 times longer. If the "in a second" part is correct, that's 1801 years. Add a special character in there and you are looking at 540360087662636962890625 combos. At 10 terahashes per second you will be through them all in some 600000 years. And that's just a simple MD5. Unix crypt does it somewhere around 1000 times over with some added flavors.
The purpose of a salt also seems to be misunderstood. It's really only there so that each password needs to be tested separately. Having something 'secret' added to the string doesn't hurt, but it doesn't add any value to cryptographic strength. It's really just a plaintext password hidden in code.
@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.
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.
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!
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
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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
. 
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.
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.
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.
I stand corrected on the random salt though - it shouldn't derive from username alone.
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.
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);
}
$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.
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...
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...
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.
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.
Jump to: