Bitcoin Forum

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! :)

Dual salts would also be good, where one of the salts set in source code. If only the database is compromised, the passwords are safe.

Of course users should:

1)  Have a 15+ character password.
2)  Have that password contain a minimum of 2 digits, 2 upper, 2 lower, 2 symbols, none repeating
3)  Have that password be unique to that site

Then you have very little to worry about, unless of course it is stored in clear text.

If only people didn't get annoyed when you try to enforce restrictions. :(

Aren't you reducing your key space then? Making it less secure.

A hashing calculation: at one billion hash comparisons a second, a 15 character alphanumeric password will take roughly 7000000 years to compare all combinations.

No, running the result through the hash function again is a very common way to make it safer.
What you basically do is, if they can figure it out, is force them to do multiple hashes for every comparison. This is a direct counter to brute-force attacks.
If they have to spend one second for EVERY combination comparison, then it will be basically impossible for them to brute-force anything.
There are even specific algorithm which are designed just for this.

If you take the above calculation, if they can only do one comparison per second instead of a billion, then it will take 7000000000000000 years instead to test all combinations for one password.

Ironically I described exactly this case this morning in my guide about passwords:


http://forum.bitcoin.org/index.php?topic=19360.0

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

I congratulate you on this! :)

I'mma release a small hashing class for secure passwords?

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

Everybody who had a crackable password in the first place is screwed when his wallet is found anyway.

The only way now is to generate a new wallet in a secure space and send the coins there.

Huh?  What does this discussion have to do with Wallets?

If you used the same password for mtgox and encrypted wallet backups, you have to create a new wallet.

Who on Earth would use their online web password for a local vault encryption?  Are you kidding me?

Have you seen how many people used their username as their password. Or 123456? I'm prepared to believe there is no limit to people's stupidity.

One thing that also got me wondering (perhaps a new topic, but as a newb I can't create a new post) was how secure the sites are which use OpenID? When you take in the password, you can insist on it's complexity, or not in the case of Mtgox. But if you are getting login credential from an OpenID provider surely you are allowing certain accounts to be wide open? Perhaps that's just tough luck for the person who's account that is.

I once read an article regarding computer & information security, and I have paraphrased its main point by the following statement, and you can quote me on this:


The article I read was referring to information security in general, but in this context, we are discussing password security.  Practically, this means predicting future innovations in the realm of password cracking/hashing, and being prepared for hash attacks by supercomputers (which is quite possible today actually, as you'll see below).  This is why I would recommend using 30-50 character passwords if possible, using lowercase and uppercase letters (no dictionary words obviously), numbers, symbols, and if possible, even using other characters that are not included on the physical keyboard (i.e., including those Unicode chars that use Alt+4 digit combinations, etc.).  For plenty of examples of these characters, you can press the Windows Key + R (if you're on Windows, of course) and type "charmap.exe" to see some of the characters I'm referring to, such as Greek letters, etc.  However, many sites can't process these kinds of characters, so sometimes it's actually better to use regular characters.

On side note, I once created a nice complex password at a certain large financial brokerage firm located in Manhattan, NYC which contained an underscore character, but the system couldn't process it, so it caused an enormous problem and I ended up being on the phone with their tier 1 technical support team who was working with the IT security engineers who had developed the database, and over the course of being on the phone with them for multiple days, we eventually discovered that a simple underscored in my password had caused major difficulties for their database, in regard to my account.  In other words, just remember to be careful when using secure passwords, since many places can't handle the length or complexity, at least not yet (hopefully they'll wake up and change their databases).

Oh and by the way, for anyone doubting that it's actually quite easy to crack passwords these days, it's important to understand that even 10 character passwords can be hacked extremely rapidly using GPUs (very similar to how us Bitcoin miners are using our cards).  For example, I know of an individual who used an array of 4 Radeon HD 5970s (each one a dual GPU, actually making it 8 GPUs) to crack hashed passwords at over 32 billion passwords a second (for MD5 hashes).  Just stop and think about that before you make another password under 10 characters long without using non-dictionary uppercase & lowercase letters, numbers, symbols, etc.

And when you create this password, what do you do with it?  You have it memorized immediately?

I use a password vault, the issue there is that I occasionally still have to type the password in by hand.  For most people having a 50 character strong password is going to be brutal, so they'll just write it down. 

If you cannot use the security measure you've adopted, you will bypass them.  That makes it useless for everyone.  I also apply different security strengths based on the site / server I'm accessing.  My Gmail password is HUGE, my banking password is HUGE, my PayPal password is HUGE, but other sites don't necessitate the same level of security.  Harden the high-value targets, always use different passwords, and adjust to what makes your security life usable.

That's just my 0.0001 BTC worth.

Can you recommend a password vault?

1Password is my favorite ( http://agilebits.com/products/1Password ).
KeePass (or KeePassX) is a good free alternative (though not as powerful) ( http://keepass.info/ & http://www.keepassx.org/ ).
LastPass in a pinch, but I don't like storing them online and trusting the service provider (didn't work out well for DropBox).

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.

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.

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.

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.

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).

Sure, here you go:


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.

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.

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...

Hey thanks!  Looks good, thinking of using it.

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.

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. :)

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 :).

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.

...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.

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.

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 (http://fora.xkcd.com/viewtopic.php?f=7&t=34237&start=80#p1349582) 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.

@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.

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! :D

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.

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.

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.

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.

Actually is ironic that a lot of BTC users were hacked using a technique mostly developed to actually mine BTC; GPU hashing.

Too bad MtGox stored the salt in the password field, next to the password.  :(

Unless you use a single admin-added salt to everyone, you need to store the salt per-user for use different ones to everybody.
Also that is the way crypt returns it:

will return something like $1$salt$klhi%$# (not exactly this hash output)

Single salt added by config can be brutte-forced if the attacker has a hash for which he knows the password, eg for md5:

Pwd: 12345
$k = 0;
while($result != $hash){
 $result = md5("12345",$salts_to_try[$k]);
 if($result == $hash) $salt = $salts_to_try[$k];
$k++;
}

"Stored per user" doesn't mean "Stored next to password, per user". 

It could have been stored on a separate system, in a separate database.  Which would have made the leaked passwords worthless without the other "half" of the password file.

No one is arguing against having per-user salts.

gmaxwell's point still stands though. A few hundred rounds of SHA512 is not sufficient. This is barely a bit more computationally intensive than MD5-based crypt(), which is not good enough and which is why MtGox and modern Linux distributions are phasing it out.

(Also an undesirable property of your hash function is that the pw/user pair "a:b:c/d" will hash to the same as "a:b/c:d" or "a/b:c:d".)

Use PHP's builtin crypt() CRYPT_SHA512 (http://php.net/manual/en/function.crypt.php) people! Don't re-invent your own crypto.

PS: I write (http://whitepixel.zorinaq.com) password bruteforcers.

This is pointless. This is the same as saying "store the hash on a separate system and make sure it does not get stolen". Hashes (and salts) both get stolen and must be designed to withstand bruteforcing as best as possible.

The point of a salt is not to be secret but to be unique. It can be stored alongside the hash. It is an industry-standard practice (think all Linux/Unix systems).

This is certainly true, but the salt/nonce can also be thrown out. Known as strengthening or stretching. Now both the server and attacker need to do extra work, just that the server at the time of authentication has much more information, namely the plaintext password.

Quick question: could a simple CRC32 (plus some additional mangling) of the login be used as a salt? That way, it wouldn't have to be stored, it just would be computed everytime it was needed.

(Only useful on closed-source projects, tho).

@netrin: stretching means iterating the hash function multiple times, eg. 1000 times for Unix MD5()-based crypt.

@an0therlr3: it would lower security to derive a salt from the username only. If an app was doing that and came with a default account (say "admin"), then every user of this app choosing the same admin pw would result in the same hash being generated everywhere.

Your suggestion is just adding a simple variation to the hashing algorithm which may prevent an attacker from using an off-the-shelf rainbow table as long as it is a unique idea. If no one knows this is your technique then it is an effective security-through-obscurity measure but if the attacker does know of this technique then an attack table can be compiled even before or while compromising the password list. And what advantage do you have over a salt? saving 10 bytes on disk per user. Sure use a hash of the username as well. I don't think it'll hurt.

This is similar to including a secret into the hash, which is compiled into code (not the password file/database). It's a fine example of security-through-obscurity as it increases the difficult or required attack vectors, but not particularly robust.

Re: the attacker knowing of the technique, that's exactly why I said it would be only useful for closed-source apps.

The main benefit isn't the 10 bytes on disk, but the fact that the salts aren't stored anywhere, so they can't be stolen unless the hacker gets to the source code, in which case the impact of the compromise is more severe than just a user/password database leak.

Netrin, with your technique the salt is known: it is effectively the username (plus a fancy hashing algo that you want to keep secret). It is trivial to reverse engineer the hashing algo of a closed source app. People have done this for Oracle, Windows NTLM auth, etc. All closed source and all have been reversed engineered and documented.

So, mrb, you made a good point for use just MD5 or RipeMD

Basically your statement is: giving enough computing power and every hash can be broken.
Well, MD5 is fast, protects you in case someone had his eyes on the database, and protect the db is the realm and responsibility of the site's owner. Going further to paranoia levels, will just make you to waste electrical power for nothing.

No. My point is: use industry standards like PHP's builtin crypt() CRYPT_SHA512 mode. They are an excellent compromise between CPU time & strength.

You have no reason to refuse to follow industry standards.

Thanks, but I respectfully deny credit for this security through obscurity technique. I stated at best this saves 10 bytes but was not robust.

So was MD5 10 years ago...

You've a GOOD reason to NOT follow industry standards actually; it's called "Rainbow Tables" and alike.
MD5 was never broken, NTLM was never broken, all of those 1-way hashing mechanisms were never broken, what happened is that they're "industry standards", so it become easy to create dbs with their possible contents.

You take this as a dogma, but security IS obscurity. Otherwise there would be no problem into have databases for all sites published in the web.
Data security is to create counter-measures for the principles of information:

WHEN - Information is only valid for a period of time, if someone tips me now that the Nazis have plans to invade Poland it is useless information, as it already happened.

WHERE - Information is only valid at some places. If I get an user/pass db but have no idea from which site it came from, I can do nothing with it.

HOW - What was used to conceal that information. If I can't figure that out within the WHEN buffer I may have useless information in hands. Using "industry standards" or "clear to all security" voids this point, as it's known what was used. The issue may be that a bad cryptographer may create a weak to break code, but variances of known algorithms can help.

If you had any education whatsoever in the area of password hashing, you would know that CRYPT_SHA512 is immune to rainbow tables thanks to its unique salt per hash. This is why you should use it instead of plain MD5/SHA1/SHA512 etc.

If you've any education you would know what Rainbow tables are and how ridiculous is that statement.
Obviously any algorithm can be stored as pre-computed hashes. Your statement is as ridiculous as to say that if I calc the hash under the same parameters at my computer it will render a different result than if I do it at yours. Yes, salt, if unknown or per-user, will prevent Rainbow Tables, but that's valid for any hashing algorithm.

To the end, how breakable it is relies on computing power, what was good at 386's time is an easy picking today, and within 10 years even your SHA512 1000 or 5000 rounds salted with any flavor may be too. But still... for what's in the market now it is nearly unbreakable.

"how ridiculous is that statement"

"Yes, salt, if unknown or per-user, will prevent Rainbow Tables"

Way to contradict yourself! This discussion is now over.

No, you imply that it can't be in a RT because of its "unique salting method", like if two computers would compute a different hash...
However this would be perfectly RT:

crypt("pass","$6$rounds=5000$myeverydaysalt$");

And unknown or per-user salt will prevent RT on every algorithm and not just SHA512

Everyone here knows Bitcoins - and Bitcoins are very, very secure.

Why not (in offline mode) create a new empty wallet.dat

Move it to removable media.

Sign in on a secure computer to your service provider and upload your newly created empty wallet.dat

When you sign in to a secure service provider the following happens VERY, VERY securely:

They spend a SMALL amount of bitcoins to the shared wallet.dat and request you to spend it back (verifying your identity and shared ownership of the wallet.dat)




With current difficulty and network hash power at ~10THash/sec it should take more than a week to brute force attack with the average PC.