julmu:

Aaron:

bcrypt.  There's an implementation available for almost every modern language/framework.

If an application has a vulnerability that can be used to get the encrypted passwords, then that vulnerability can be probably also be used to get the key that was used to encrypt the passwords.
If you get that key it will be easy to decrypt all the passwords.

 

No. bcrypt is one-way hashing. Decrypting is only possible through brute-force attacks, but those are very expensive in terms of computing power with bcrypt.

ammoQ:

No. bcrypt is one-way hashing. Decrypting is only possible through brute-force attacks, but those are very expensive in terms of computing power with bcrypt.

Are we talking about the same bcrypt? I thought you were talking about http://bcrypt.sourceforge.net/

Quote from that website:

Encrypted files will be saved with an extension of .bfe. Any files ending in .bfe will be assumed to be encrypted with bcrypt and will attempt to decrypt them.

I haven't tried it so I don't know how it works. I assumed that the decryption feature means that it's reversible, not that it's brute-forcable.

julmu:

ammoQ:

No. bcrypt is one-way hashing. Decrypting is only possible through brute-force attacks, but those are very expensive in terms of computing power with bcrypt.

Are we talking about the same bcrypt? I thought you were talking about http://bcrypt.sourceforge.net/

Quote from that website:

Encrypted files will be saved with an extension of .bfe. Any files ending in .bfe will be assumed to be encrypted with bcrypt and will attempt to decrypt them.

I haven't tried it so I don't know how it works. I assumed that the decryption feature means that it's reversible, not that it's brute-forcable.

 

Actually no, we are not talking about the same thing. We were talking about this thing:

http://www.usenix.org/events/usenix99/provos/provos_html/index.html

bcrypt is definitely the right solution to such problems.  if for whatever reason that's not an option, it's trivial to make make the algorithm upgradable while retaining backwards compatibility with old schemes.

i'm baffled by comment #3 though.  what's the secure alternative to cryptographically hashing passwords?

ligne:

if for whatever reason that's not an option, it's trivial to make make the algorithm upgradable while retaining backwards compatibility with old schemes.

Not sure what you're suggesting here.

 

ligne:

i'm baffled by comment #3 though.  what's the secure alternative to cryptographically hashing passwords?

Assuming you are talking to me, then I was referring to using traditional hash functions like MD5 or SHA instead of one more closely based on a block cipher like bcrypt.  I figured that was clear enough from the comment itself, and definitely from the conversation that ensued. 

Hashing without salts is stupid (as all of us here hopefully know) -- A password of 5 characters per-se no matter WHAT algo you put it through will still be 5 characters, just be hashed, alas easily cracked. It doesn't matter how good of an hash you use (you could use sha512 for all intents and purposes). If what you feed that algo is crap (i.e. insecure), your security will still be equally crap.

Regarding salts: Salts are good and all, but in reality, it just places a small barrier up in place, One can still likely cause collisions with salted passwords regardless of what the salt is, especially if one can find out how the salt is generated.

The ultimate goal of hashing should be is to stop the casual password snatcher, but someone who's experienced, has knowledge and compute power will be still able to break whatever you do, the goal should be to prevent your databases from getting compromised in the first place. Point is: Hashing... Salts... Passwords, you can put as many layers up as you want, but ultimately, as long as the system is manmade and is designed under finite capacity, it is imperfect and can be broken. If you're that paranoid that you cannot trust any security method (even tentitively). Don't. Don't store any sensitive data at all anywhere.

Your best chance with passwords is to keep them changing to upset any sort of brute force/cracking methods. One should not depend on static passwords/salts as stated above, the hashing/salting is imperfect and will be broken.

As the addage goes: Security is a journey, not a destination. 

morbiuswilters:

ligne:

if for whatever reason that's not an option, it's trivial to make the algorithm upgradable while retaining backwards compatibility with old schemes.

Not sure what you're suggesting here.

basically, any technique you can think of to specify what algorithm was used to hash a specific password. whether that's an extra column in the database, or encoding the mechanism within the hash -- for example using the various extensions to good old crypt() [1], or the {crypt} or {SSHA} strings prepended to password fields in LDAP. upgrading then becomes a matter of adding a little (more) logic to identify the algorithm in use, and use the appropriate mechanism to verify the password. cue backwards compatibility at more or less no extra cost. [1] http://www.openwall.com/crypt/openwall-crypt.3.ps.gz

DigitalXeron:

Hashing without salts is stupid (as all of us here hopefully know) -- A password of 5 characters per-se no matter WHAT algo you put it through will still be 5 characters, just be hashed, alas easily cracked.

this can lead to great amusement. viz. steven murdoch using google as a rainbow table.

Regarding salts: Salts are good and all, but in reality, it just places a small barrier up in place, One can still likely cause collisions with salted passwords regardless of what the salt is, especially if one can find out how the salt is generated.

more importantly, they'll only protect you from, say, someone running a whole database through JtR and getting every password in a single. if the attacker wants a particular account's password, there won't be any tangible benefit.

DigitalXeron:

Regarding salts: Salts are good and all, but in reality, it just places a small barrier up in place, One can still likely cause collisions with salted passwords regardless of what the salt is, especially if one can find out how the salt is generated.

What the fuck?  Have you read any of this thread or did you just jump in at the last minute with nonsense?  The point isn't to create collisions and salts are not a small barrier.  Jesus.

 

DigitalXeron:

The ultimate goal of hashing should be is to stop the casual password snatcher, but someone who's experienced, has knowledge and compute power will be still able to break whatever you do, the goal should be to prevent your databases from getting compromised in the first place. Point is: Hashing... Salts... Passwords, you can put as many layers up as you want, but ultimately, as long as the system is manmade and is designed under finite capacity, it is imperfect and can be broken. If you're that paranoid that you cannot trust any security method (even tentitively). Don't. Don't store any sensitive data at all anywhere.

The ultimate goal of protecting the passwords should make it virtually impossible for anyone to find the passwords in a reasonable amount of time, barring significant advancements in cryptography.  THAT IS THE POINT.  Keeping the databases safe has nothing to do with what we are talking about.  We are talking about providing an extremely difficult to break method of password storage.  That is what the libraries I suggested using will do for you.  Use them and stop pretending you know what you are talking about.

 

If you're going to contribute something to a discussion in the future please read the thread first so you know what has already been said.  It would also help if you had a clue what you are talking about. 

Is MD5 really that bad? I mean, I know it's not the best hashing algorithm ever invented, but with a decent length per-password salt generated that makes it fairly resistant to rainbow tables and a hell of a step up from plaintext right?

True bcrypt etc will hold out longer against brute force from someone who has the seed and the hash, this is true, but I thought MD5 with a quality salting would hold it's own for a long time. Though I guess end of the day once they have the salt the time it takes depends on the quality of the hashed password (Seeing as with distinct salts they can't really rainbow it they'd have to go after specific ones), so for an easier to dictionary-attack password bcrypt's advantage might keep them safe... Is that the only real advantage?

Sure md5 is no longer sufficient for signing a file to prove it wasn't tampered with due to collision finding, but that's not really even the same ballpark right?

NB: I know "It's better and no difference in effort" is a convincing argument regardless of how small, but I just want to be clear just how bad MD5 really is...

fyjham:

Is MD5 really that bad? I mean, I know it's not the best hashing algorithm ever invented, but with a decent length per-password salt generated that makes it fairly resistant to rainbow tables and a hell of a step up from plaintext right?

Obviously it's better than plaintext.

 

fyjham:

...but I thought MD5 with a quality salting would hold it's own for a long time.

It can hold out for awhile, but why would you choose something that is significantly easier to break?

 

fyjham:

Though I guess end of the day once they have the salt...

What?  Obviously they have the salt.  It's not a secret value.

 

fyjham:

Seeing as with distinct salts they can't really rainbow it they'd have to go after specific ones...

You need to read this thread before posting stuff like this.  A rainbow table built out of a dictionary and every single salt is not inconceivable.

 

Any password storage scheme that is put in place today will mostly likely be in use at least 5 years from now.  To throw your lot in with an extremely fast algo like MD5 that has already been shown to have many flaws is absolutely stupid and irresponsible.  Once again: you need to stop worrying about things like this and use a well-tested library designed by experienced crypto experts.  bcrypt is probably best-of-breed right now although there are some decent alternatives available.  Do not roll your own.

To throw your lot in with an extremely fast algo like MD5 that has already been shown to have many flaws is absolutely stupid and irresponsible

[citation needed] that MD5 has been shown to have any flaws relevant to password hashing or that any crypto expert has recommended against its use for that purpose.

Random832:

[citation needed]

Do your own goddamn homework.  You can believe me or you can roll your own sub-par password storage solution.  I could really give a shit.

 

Random832:

that MD5 has been shown to have any flaws relevant to password hashing

MD5 has many flaws relevent to password hashing, including the fact that it is fast and that it is no longer considered cryptographically secure.  Crypto experts have been advising against its use for at least 10 years now as it was well-known that it as only a matter of time until flaws were uncovered.  Considering the holes that have been shot in it, I wouldn't be surprised if it was soon announced that it was possible to reverse the algo with relative ease.

 

Random832:

that any crypto expert has recommended against its use for that purpose.

You obviously don't know much about cryptography.  MD5 has been considered a joke for awhile now.  Only the uninformed were surprised when serious flaws were uncovered and it became significantly easier to mount preimage attacks.

 

Seriously, if you have nothing new to add to this thread, let it die.  I've advised people on best practices here and all you are doing is jumping in at the last minute and trying to spread uncertainty on a topic you have no fucking clue about.  Anyone writing a new piece of software today should be using bcrypt.  End of discussion. 

morbiuswilters:

You need to read this thread before posting stuff like this.  A rainbow table built out of a dictionary and every single salt is not inconceivable.

It is conceivable, although most rainbow tables are built from brute-force input so it's somewhat of a moot point.  An RT will, by definition, contain every single salt, as long as the character length of password + salt is within the RT's scope.  If you have a 13-character rainbow table then it will intrinsically cover every password up to 8 characters with any 5-character salt.

The bottom line is that by using long salts to extend the password length with a fast hash like MD5, you're betting against Moore's Law, which is positively the worst thing to bet against.  People need to remember that even though it might be impractical now to mount an attack with your 20-character salt, you're going to have that exact same password database sitting around 5 or 10 years from now because it's almost impossible to migrate reliably to another authentication system.  Going with a "slow" algorithm like bcrypt, you're not bound (well, less bound) to Moore's Law; instead, you're betting against major scientific or technological advancements in cryptography, which tend to be a lot less frequent than hardware improvements.

And you can't just use ridiculously long 50-character salts either; extending the passwords by that much dramatically increases the risk of collisions (no, I'm not talking about message-signing collisions, I'm talking about two password + salt pairs hashing to the same result).

Given the choice, I would prefer to have my password stored in a form that will still be secure in 25 years, as opposed to one that might not be secure 5 years from now.

Oh, and about the TLS thing which I missed the reply on before - there is such a thing as a partially trusted environment, for example, a corporate network.  A disgruntled and determined enough employee can still do plenty of damage, but at the very least, they can't just pop open Ethereal and see everyone else's passwords (including the administrators) fly by.

Slightly offtopic but please bare with me.  I would be interested to know what you suggest is a better hash checksum than MD5 and SHA-1.  I don't pretend to know half as much about cryptography so please bare that in mind.

Alternatives: SHA-512, Tiger, Whirlpool, HAVAL, RIPEMD etc.

Secondly, is there a list of tools that use bcrypt anywhere.  Apart from the original article, this was the only thing I spotted on i:

http://en.wikipedia.org/wiki/OpenBSD_security_features#Cryptography_and_randomization

 

morbiuswilters:

It can hold out for awhile, but why would you choose something that is significantly easier to break?

Mmm, I agree, that's what I was saying when I said:

fyjham:

NB: I know "It's better and no difference in effort" is a convincing argument regardless of how small, but I just want to be clear just how bad MD5 really is...

I'm not trying to imply MD5 is better, or even a passable alternative given how easy it is to just do the other options. My interest was purely theoretical as to what weaknesses in MD5 really existed and to what extent it was simply that a more future-proof option was readily available.

morbiuswilters:

You need to read this thread before posting stuff like this.  A rainbow table built out of a dictionary and every single salt is not inconceivable.

Ah, my bad. I did read it, but apparently not well enough. Gave it a re-read and saw what you meant... I guess that is concievable if the passwords were valuable enough to justify the considerable effort. You could always push up the size of the seed and it'd quickly become impractical to build a decent rainbow table (Though obviously doing the same with bcrypt is even more effective and eventually you'd wind up with an unmanagably large seed).

Aaron:

And you can't just use ridiculously long 50-character salts either; extending the passwords by that much dramatically increases the risk of collisions (no, I'm not talking about message-signing collisions, I'm talking about two password + salt pairs hashing to the same result).

Which is irrelevant because an attacker can't choose to use a different salt than the one that was actually used (if the person attempting to log in could supply their own value for the salt, it wouldn't be a salt - it would be part of the password)

Random832:

Which is irrelevant because an attacker can't choose to use a different salt than the one that was actually used (if the person attempting to log in could supply their own value for the salt, it wouldn't be a salt - it would be part of the password)

 

Not quite.  If you find a collision then you now have access to the prior stages of the hash function, which makes it easier to find other collisions (and therefore the original password).

In many cases this is also going to depend on the exact implementation of the auth system.  Most hashing implementations I've seen first ask for the salt, then use it to hash the user-supplied password and submit the result to an authentication function.  This would obviously be a requirement if the salts were stored in a separate location.  Depending on the architecture, it's often possible to exploit collisions by discarding the result of that first step or bypassing it entirely and going directly to the authentication function.

A cracker doesn't have to use your web-based login form to authenticate.  Chances are, if he's managed to get your password database, he can find a way around your front-end.

Aaron:

A cracker doesn't have to use your web-based login form to authenticate.  Chances are, if he's managed to get your password database, he can find a way around your front-end.

Son of a bitch..  you seemed pretty intelligent up until this point.  Passwords are not hashed for the purposes of protecting access to your system.  If someone has the password hashes it is safe to assume that they have compromised every aspect of the system.  Regardless, that is not the point of hashing passwords.  The purpose is to prevent a user's password from being visible to an attacker since users frequently use the same password for different services. 

morbiuswilters:

Passwords are not hashed for the purposes of protecting access to your system.  ... The purpose is to prevent a user's password from being visible to an attacker since users frequently use the same password for different services. 

Solution:  a checkbox when they sign up for an account which MUST BE CHECKED.  By checking the box, the user verifies that s/he does not use that password on any other service. 

THEN we can store plaintext passwords and not have threads that go on and on because people don't listen.

morbiuswilters:

Aaron:

A cracker doesn't have to use your web-based login form to authenticate.  Chances are, if he's managed to get your password database, he can find a way around your front-end.

Son of a bitch..  you seemed pretty intelligent up until this point.  Passwords are not hashed for the purposes of protecting access to your system.  If someone has the password hashes it is safe to assume that they have compromised every aspect of the system.  Regardless, that is not the point of hashing passwords.  The purpose is to prevent a user's password from being visible to an attacker since users frequently use the same password for different services. 

Or if you have a braindead design that discloses all password hashes to all users (read: unix)

Random832:

Or if you have a braindead design that discloses all password hashes to all users (read: unix)

That's not been the case in unix for quite some time.