And store the password encrypted...



  • @julmu said:

    @Aaron said:

    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 said:

    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 said:

    @ammoQ said:

    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 said:

    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 said:

    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 [b]prevent your databases from getting compromised in the first place[/b]. 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 said:

    @ligne said:
    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 said:

    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 said:

    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 said:

    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 said:

    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 said:

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

    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 said:

    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 said:

    [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 said:

    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 said:

    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 said:

    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 said:

    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 said:

    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 said:

    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 said:

    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 said:

    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 said:

    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 said:

    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 said:

    @Aaron said:

    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 said:

    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. 



  • @Random832 said:

    Or if you have a braindead design that discloses all password hashes to all users (read: unix)
    Um... shadow passwords ... or using LDAP for auth will hide the passwd hashes. (Which was something I mentioned earlier).

    Password hashes are irreversible, the point is to make collisions rare, and the algorithm computationally intensive enough so it renders brute-force attacks unfeasible.



  • @danixdefcon5 said:

    @Random832 said:

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

    Which are a relatively recent development as unix history goes, aren't they?



  • @Random832 said:

    Which are a relatively recent development as unix history goes, aren't they?
    Looks like they have been around since System V release 3.2, which was released in the late 1980s... ancient in computer terms.



  • @WeatherGod said:

    @Random832 said:

    Which are a relatively recent development as unix history goes, aren't they?
    Looks like they have been around since System V release 3.2, which was released in the late 1980s... ancient in computer terms.

    Yeah, no shit.  I've been using unix for almost half my life and I've never seen a system that didn't use shadow passwords. You might as well talk about bugs in Windows 95.



  • @Aaron said:

    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.

    That pretty much sums up cryptography in general. The best you can do is slow an attacker down, and every little bit helps.



  • @morbiuswilters said:

    If someone has the password hashes it is safe to assume that they have compromised every aspect of the system.

    If someone has the password hashes, it is likely that they have compromised every aspect of the system, but it's not safe to assume that.  Many things are likely to occur at the same time in the event of a security compromise, but responsible architects normally use some kind of defense-in-depth strategy just in case.

    In the case of a password database, it can very easily happen that somebody has managed to obtain read-only access (example: SQL injection).  In a transactional environment (let's say a bank, or broker), if the hashes turn out to be uncrackable, there's not a lot of damage that can be done with this.  However, plenty of damage can be done if one of those hashes can somehow be used to log into the account of someone with administrative or write privileges.

    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.

    That is one purpose, perhaps the primary purpose, and a very logical one.  However, for someone who makes a point of denigrating the intelligence of others for disagreeing, I would expect you to be aware of the common wisdom that the majority of security threats come from the inside.  It is not likely, but most certainly is possible, for someone to walk away with your password hashes without actually compromising the entire network, and security is rarely an exercise in predicting the likelihood of a risk, but rather an exercise in containing the scope of a disaster.

    The term is fail safe, and if you've made the decision not to concern yourself with replay attacks then that is your business, but don't pretend that they don't exist.  And in the case of MD5, a non-matching collision does in fact make it easier to conduct a replay attack.  If you consider this to be pointless academic esoterica then, again, that is your business, but does it not seem odd in that case that there are so many researchers in the field working on precisely these types of problems?



  • @Aaron said:

    @morbiuswilters said:

    If someone has the password hashes it is safe to assume that they have compromised every aspect of the system.

    If someone has the password hashes, it is likely that they have compromised every aspect of the system, but it's not safe to assume that.  Many things are likely to occur at the same time in the event of a security compromise, but responsible architects normally use some kind of defense-in-depth strategy just in case.

    In the case of a password database, it can very easily happen that somebody has managed to obtain read-only access (example: SQL injection).  In a transactional environment (let's say a bank, or broker), if the hashes turn out to be uncrackable, there's not a lot of damage that can be done with this.  However, plenty of damage can be done if one of those hashes can somehow be used to log into the account of someone with administrative or write privileges.

    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.

    That is one purpose, perhaps the primary purpose, and a very logical one.  However, for someone who makes a point of denigrating the intelligence of others for disagreeing, I would expect you to be aware of the common wisdom that the majority of security threats come from the inside.  It is not likely, but most certainly is possible, for someone to walk away with your password hashes without actually compromising the entire network, and security is rarely an exercise in predicting the likelihood of a risk, but rather an exercise in containing the scope of a disaster.

    The term is fail safe, and if you've made the decision not to concern yourself with replay attacks then that is your business, but don't pretend that they don't exist.  And in the case of MD5, a non-matching collision does in fact make it easier to conduct a replay attack.  If you consider this to be pointless academic esoterica then, again, that is your business, but does it not seem odd in that case that there are so many researchers in the field working on precisely these types of problems?

    Right. That was my point when I mentioned using LDAP instead of the RDBMS for password storage. It separates the entire authentication schema into another entity, and making it harder to get to the passwords. So even assuming someone got read-only SQL access, they still can't get to the password hashes. Plus, having the authentication itself happen in another entity reduces application logic to a simple loginLDAP(user,pass); which may or may not be protected by SSL.

    I already mentioned LDAP/RACF pairings, an interesting note here is that someone cracking one of those logins would have mainframe access, and could do a lot of damage there. So having unobtainable hashes becomes something even more important!

    I've worked in places where the "security" layer is very extensive, having reverse authentication proxies before even reaching the application server. Financial institutions (especially banks) will want to lock out every single point of entry. I admit I had a very paranoid boss when in that area (up to the point of prohibiting us to send public certs to anyone outside IT Security) but he did make sense in some of these measures.


Log in to reply