Slashdot Mirror
Are You Sure SHA-1+Salt Is Enough For Passwords?
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."
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?
I'm not a lawyer, but I play one on the Internet. Blog
Why is this even a question? Use bcrypt, always. (Preferably using the $5$ or $6$ extensions.)
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.
Palm trees and 8
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.
John
May I be the first to congratulate you on your insightful, interesting and well written post. It's amazing you managed to do all that, and do it before anyone else. You really do make /. what it is. Thanks!
Salts just mean they can't use precomputed rainbow tables, salt length should be long enough to make existing rainbow tables useless. This isn't hard.
Once someone is in your system with root/admin accesses, you're already hosed.
Most users will create the least-secure password which still meets the restrictions you've set upon them - whether that's 8-10 chars with 2 upper/lowercase, 2 digits, and 2 specials or a 16/32/64 digit extravaganza.
My philosophy is to make a very secure password and then keep it written and on my person until I completely memorize it. It doesn't have to make sense, it sure as hell won't be my anniversary or birthday. You've got a much less likely chance of kicking my ass and taking that piece of paper, compared to setting up a script to crack it.
To this day, the most secure form of sending a message is still a live messenger - codes can be cracked and transmissions can be intercepted. People are harder to break.
What you want to use is something that will not be trivial to brute force. Instead of doing 2300 million attempts per second, you want something that limits an attacker to 10,000 or 100,000 attempts per second.
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.
What else can happen when an unstoppable force collides with an immovable object?
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
No, the moral of the story is to use a hash that takes a long time to compute.
My entire system is encrypted, and when the passphrase is hashed, 2**23 rounds of SHA-256 are used (takes something like 13 seconds on my P4 2.4). Plus, of course, a salt is used.
This won't protect against stupid passwords, but it will really help against brute-force.
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.
Never ask for directions from a two-headed tourist! -Big Bird
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/
Atari rules... ermm... ruled.
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...
No sig today...
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" anyway, don't they?
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.
My karma is not a Chameleon.
No, the moral of the story is to not do any of those things, since your box is going to get hacked anyway.
"I'd just like to emphasise that taking a million years isn't a metaphor here..." -Rich Bradshaw
First post!
Your failure to properly encrypt your post has left it vulnerable to many eyes. Maybe you should have RTFA?
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.
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?
My blog. Good stuff (when I remember to update it). Read it.
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 password reset process.
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
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.
The first time I heard that "film at 11" thing, I thought they meant airing a movie at 11 PM.
Circumcision is child abuse.
Slow by design.
I've always wanted to experiment with this, but I've never tried it. If you're using something open like PHP, recompile the binaries with your own modifications to the md5() algorithm (or whichever function you're using). It doesn't have to be anything significant, but changing a few constants or routines and/or hard-coding a salt would make it pretty much impossible for someone to successfully attack the hashes without first realizing your trick, getting access to the binary, and reversing it.
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 has access to the encrypted passwords, salts and your code... it sort of seems like a given that you are (a) screwed and (b) they can brute-force the passwords with a much higher success rate.
I was thinking salting was just helpful when the passwords got exposed/stolen but the rest of the machine/code/etc. wasn't compromised. (not sure when that actually happens, but hey)
In fact the first post is almost as much interesting as the whole story. Melchett does not understand very well the purpose of salts and want to share with us its ignorance.
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.
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.
Chas - The one, the only.
THANK GOD!!!
Desktop supercomputers (GPUs) are cheap nowadays. Modern GPUs can process over 3 billion (yes, billion, with a B, http://www.golubev.com/hashgpu.htm) 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 obviously to avoid re-using passwords for different services, and if people actually followed that in practice it wouldn't be such a big deal for an attacker to gain access to the password plaintext, because if they have the hash database they probably have already compromised the site / system anyway, and getting the passwords wouldn't help them get any further access to other systems.
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.
May the Maths Be with you!
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.
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 address + plaintext password + some secret string of a random nature.
That means that even if the attacker stole my database they would not be able to dictionary attack it unless they also had the secret key. So at a minimum the secret should not reside in the same db as the hashes. Better yet, the hasher should not reside in the same process as the login server, better yet it should be on a different, protected box with a well defined API.
"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.
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?
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.
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 other techniques, being as how it's largely considered easy to collide. Personally, I'd use an HMAC with SHA. I'd properly pad the passwords to be a full block in size and I'd pick a very random pass-phrase. Standards groups have helped design them with security in mind, where as the bcrypt proponents largely point to the speed of bcrypt as its biggest advantage.
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.
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.
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 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 - 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 - 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/
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.
This may all be true, but isn't necessarily of a lot of practical value in real-world applications. If an attacker has gained root access, one has to assume they've compromised every part of the system, including changing any number of binaries for their nefarious purposes, and taking the passwd file for later perusal. In this case, whether the hash takes hours or months to crack, the only way to be sure the attacker won't have anything useful is to reinstall everything from media and force everyone to reset their passwords to something other than what they were before.
More computationally expensive password hashing algorithms are a band aid on the real problem, which is the fact that once an attacker has gained access to root, containing the damage becomes orders of magnitude harder.
Anybody halfway competent knows that you need to iterate your hash to create a certain attack effort. Then you need to selecti iteration count to create a certain, desired attack effort. Even the venerable, DES-based original UNIX crypt function already did this. Today there are multiple, well established options like PBKDF2, besides just iterating a standard hash for, say 1 second on a current CPU. People doing a single hash iteration are simply incompetent and did not research the issue at all.
Not news, just people with no clue about cryptography or IT security implementing broken security functionality that is easily cracked.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
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.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
You have already lost everything. Just edit the login form to mail all the passwords to you and kill the session table. Done. No amount of salting trickery will save you.
The article is kinda stupid too - who in the world still uses a static salt? Most proper frameworks like django use algo$salt$hashed value in the database, so the developer can switch algorithm any time and have it applied on next login and use unique salt values per user. Running SHA1() a hundred times won't turn a polynomial time problem into exponential time, there will always be a better GPU next year which can create rainbow tables just as easy.
Just save the "password" as a three part tuple and use unique salts. You'll be safe until they finally get quantum computers working.
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 for many people).
The problem with the "dynamic hashing" solution to the problem is it fails to account for the fact that a devoted attacker is going to be willing to dedicate vastly more resources to cracking it than you are to securing it. Dynamic hashing grows linearly with the amount of computing power used to secure it vs how much it takes to break it. So, for very weak passwords, rather than it taking .1 seconds to crack, it takes five minutes, which is not likely to deter any attacker.
It might deter someone from cracking a large range of passwords to your systems, or someone from guessing the password to your blog's administrative account. But it's not something you can rely on for systems that would be targeted by devoted attackers. At the end of the day, weak passwords cannot be made a secure authentication method.
Think about a car. You can install an alarm, tint the windows, deploy the Club(tm), lock the doors, and point a camera at it. However, no matter how many security precautions you take your vehicle can still be broken into and/or stolen. Security is about deterring criminal behavior. There is no way to completely eliminate that risk - it can merely be reduced. The same concept applies to Web application security. I'm not saying you shouldn't bother encrypting (that would be unwise), but you shouldn't assume that encryption will protect you.
... or he could backdoor the passwd program. I think GP was just trying to make a point about computationally difficult hashes and made a bad choice of words.
Simply put: No.
They get your salt and your code, sure... but try to figure out what hashing is and why we use it before uttering such complete nonsense.
Unless it's something like a web application server, in that case they'll just install something to grab unencrypted usernames and passwords as they are input.
When an attacker has root access, all bets are off.
You can force people to need passwords, but you can't force them to care. A lot of accounts on a lot of sites are considered disposable by a large number of people. Therefore, they'll always choose a password that's as trivial as allowed.
Ita erat quando hic adveni.
It's quite reasonable to expect real databases to handle things like login and storing the passwords, especially if they're already storing users. This is, after all, what databases are for: data management. If you want multiple applications to use the same database (and you should, because databases are integration technology, not merely storage technology) then you want them all to be able to authenticate the same way, easily, and you want that functionality managed centrally with the data itself. PostgreSQL's supplied pgcrypto extension has a crypt function that works like bcrypt and uses whatever salt is stored in the password hash. The documentation shows how to use this to implement secure password storage and authentication.
Of course, if you're using MySQL, you already have an architecture problem.
Is that sufficient, or indeed secure? Given enough resources, a hashtable chain of 1,000,000 iterations could be generated for all systems, then only the first table in the chain iteration is needed anyway for a final lookup.
Unless the system uses the salt at each hashing step? But in this case, does this affect the distribution of the hashes? I don't know the details, but simply iterating a simple hash does not seem like a true solution to the problem.
May the Maths Be with you!
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, 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.
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.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
TFA is suggesting a pointless solution, though. TFA suggests that instead of an algorithm that allows an attacker to check 2300 million hashes per second, we use something that can limits current hardware to 10 thousand per second. That's all well and good, except that Moore's law will raise that back to 2300 million after 27 years... and that's assuming that the ability to generate these things doesn't increase faster than Moore's law. Certainly the introduction of GPGPU computing gave us a performance leap far in excess of Moore's law for this sort of stuff. A willingness to increase power consumption, for example, allows you to scale performance beyond Moore's law.
The author suggests that we use an algorithm where "Computational time required can be adjusted easily when processing power increases" but this doesn't completely solve the problem; keys generated before changing the algorithm will still be crackable with the old processing requirements.
I remember people like Thomas Ptacek warned against it years ago, particularly after a fiasco started by a blog article on Coding Horror on rainbow tables.
Articles like this annoy me, because it assumes that security is binary. Either your system is secure or it is not. That's crap. Security goals are defined relative to the sensitivity of the resources being protected, and to the aims of the organization.
The real problem is not how you are storing your passwords. The real problem, if your organization is trying to protecting something of value, is that you are relying solely on passwords to begin with. Multifactor authentication, intrusion detection/prevention systems, and auditing are minimums for real security. And, hey, if you're protecting something really sensitive, say the control system for a nuclear reactor, then toss on RBAC with separation of duty.
So I really don't care that Gawker got hacked and their passwords leaked, because those credentials should not be sufficient to access any resource of significant value.
Wait , then what does it mean exactly ?
Slipping shoelaces ?
One reason people use MD5 and SHA1, even if they may not be optimal for a particular purpose, is that they're universally available. For example, any standard install of perl or ruby has MD5 available without installing any additional libraries. I have a perl application that I originally wrote using SHA1 for watermarking, but I started getting worried as I heard reports of SHA1 collisions being generated successfully and of possible weaknesses being found in SHA1 by cryptanalysis. I upgraded my software to use the Whirlpool hash, but that was a massive pain, because the perl implementation of Whirlpool hadn't been packaged conveniently for Debian/Ubuntu. What we really need is for a greater variety of state of the art crypto algorithms to be packaged conveniently, so that people will actually USE them.
Find free books.
Here is a writeup on why salting AND iteration counts on password key derivation function matters: http://blog.josefsson.org/2011/01/07/on-password-hashing-and-rfc-6070/ Salting by itself has been known to be insufficient for decades.
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).
Unless the attackers stored the original hash first , then resets the password , and puts the original hash back after he's done.
Slipping shoelaces ?
If a burglar climbs in through your window is a dead bolt on your door enough to keep him out. This and more at 11.
It takes time to develop the film, so that's why it can't be shown at 6 o'clock. "We'll show the film at 11," became a standard catchphrase during the 50s, 60s, and 70s.
Then the portable videotape was invented in 1982 (VHS-C and Betacam), and that eliminated the delay of film development.
Information wants to be expensive AND wants to be free. So you have Value vs. Cheap distribution fighting each other.
Language changes and evolves. News at 11.
Grammar nazis on the moon. News at 11.
The purpose of a salt is to compartmentalize a password hash. I agree with what you said, I just wanted to add a quick soundbyte to use when explaining why a salt is needed for say, anything above 10 users.
It takes a man to suffer ignorance and smile
Be yourself no matter what they say
You're spot on. All it takes is one $0.02 sticky note with a Mult1pl3.R3str1c71Ons.En4rced password written on it to make all this huff and bluster worthless in most IT environments.
People seem to forget that Users use computers. Not Security Nuts. Not IT staff.
Real security accounts for social factors. The reason the Sup3r!Pa55w0rd policy fails is the same reason the easiest way into a network is often social engineering. Users. Security is not purely technological problem.
Security starts with taking your weakest link into account. Hint: It isn't that your "10 character minimum, 2 character subset" requirement is too weak.
~Dalcius
Rome wasn't burnt in a day.
Yes, if an attacker roots your box, you have a much bigger problem. But the point is that you now have two problems: your box is rooted, AND all your customers' passwords are exposed.
Those are not two problems. The problem "your box is rooted" is simply another way of saying "all the data on or transiting the box is exposed to the attacker". So, you can't then go and describe as separate problems from the "your box is rooted problem" each of the categories of data that happen to be on the box being exposed.
It's like warning for the danger that the thief driving away with your brand new car now has the ability to pick its door lock.
The issue might be more relevant for passwords passing over a network in clear text - but there are better solutions for that, llike https.
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 quite reasonable to expect real databases to handle things like login and storing the passwords, especially if they're already storing users.
That's not his point. His point is that if you send the password in plain-text to MySQL for hashing and comparing, it's a security hole in the application design. The password is now traveling over a network in plain-text and would be trivial to intercept. It's as easy to sniff unencrypted MySQL traffic as it is to sniff unencrypted HTTP traffic.
The problem with non-password solutions amounts to two issues: Key Portability and Certificate Revocation.
So you have this nice certificate based system with known ecosystem of trusted servers and clients. How do the user add a new client? How does the admin go about revoking a compromised one? Biometrics guarantee a portable, complex private key, but cannot easily be revoked. certificate key files can be revoked but are now not very portable (without compromising security). The fact that the modern internet relies on extremely portable access, the moving of certificates is a big issue.
Make sure everyone's vote counts: Verified Voting
I would hope your web server doesn't have access to /etc/shadow ...
GLaDOS for President 2016! "Well here we are again. It's always such a pleasure." -- GLaDOS, 2011
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.
I hadn't the slightest objection to his spending his time planning massacres for the bourgeoisie... (P.G. Wodehouse)
Ulrich Drepper has an interesting article from 2007 about updating the UNIX crypt() command to support SHA-256 and SHA-512.
This is currently used in several modern Linux systems, such as Fedora and Ubuntu. I haven't a clue if any of the BSD systems use it.
It does not appear to be rolled into GNU crypt, at least not according to its documentation.
GLaDOS for President 2016! "Well here we are again. It's always such a pleasure." -- GLaDOS, 2011
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 for many people).
All that work and in the end you effectively have a single password for everything.
Passwords are like testicles in a devil's threeway - you must never let them touch.
i think the default is that it runs 5000 rounds of that hash for your passwords. if you are really paranoid like me then put something like this in your /etc/pam.d/common-passwd
password required pam_unix.so nullok obscure min=8 max=20 sha512 rounds=250000
this needs a few seconds on a 2.5Ghz AMD. so you should be safe against dictionary attacks as long has your password is not 12345678 or april1
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 then de-combine the known salt and have the password! Simple.
Finally, because the salt is combined with the encryption key, using one salt for your whole system would be no different to just using a different key.
With the correct scheme, adding a per-user salt means (even if the salt is trivial to discover) you are using a DIFFERENT key to compute the hash for each user. Now you may still be able to generate a large look-up table of hashes to compromise an individual hash, but it will only work for ONE user account (barring salt collisions), and so a 24-hour run (your number) will be required PER USER ACCOUNT. This means that a few dozen, or even a few hundred, accounts may be compromised, but this will be a much smaller fraction than if you weren't using salts (or were using them incorrectly, as is so common).
Then the portable videotape was invented in 1982 (VHS-C and Betacam), and that eliminated the delay of film development.
But the U-Matic cassete was introduced in 1969, it was compact enough, the quality was good enough, and networks certainly used it. But they kept doing the "film at 11" thing, I assume, simply because audiences were used to it.
Circumcision is child abuse.
That's still missing the point. The point is to be able to crack the passwords held in the database back-end of the webapp. There are other ways to get at the customer data if you're already that far in, but as the gawker incident shows, many people re-use passwords across multiple web accounts, so depending on the nature of your caper you'll want to know what those passwords are so you can try them in other locations as well. /etc/shadow doesn't even have to come into play here, and shouldn't.
You are making very strong assumptions about your AES256 implementation (or what ever other block cipher).
On a technical note you assume that whoever coded the implementation of AES did not chose to make it so that it only decrypts a ciphertext with a valid password and otherwise returns "fail". This is trivial to implement: to encrypt m as 0000...000|m. To decrypt, first decrypt then check if the result has 0000...000 as a prefix. If not output "fail" otherwise output m. This this could well be considered a "useful" feature of the implementation as it avoids higher level applications using AES from having to deal with bad passwords.
More formally, from a crypto stand point you also make un-realisable assumptions. A block cipher is essentially pseudo-random permutation. You are suggesting that selecting a random PRP p1 from the AES family (i.e. a random password), computing it in the forwards direction to get p1(m)=c, then selecting another (arbitrary!, not random) PRP p2 from the family and then inverting it to get p2^-1(c) = m' would give you a uniformly distributed m' that is independent of m and p1. No way. Formally you are assuming AES is a family of (invertible) random oracles! But it's trivial to see that random oracles can not be implemented by any poly-time algorithm. So regardless of how it is implemented this can not possibly be more then a heuristic.
Conclusion: don't assume decrypting with a bad password gives a random output independent of the message in the ciphertext. This is an extra (and formally a false) assumption on your implementation!
But it is rolled into glibc, and into libc on Solaris, and elsewhere.
We ported Drepper's SHACrypt() to Java for Ganymede, and use it for password hashing.
- jon
Ganymede, a GPL'ed metadirectory for UNIX
Stop using passwords. Passwords suck.
Any time you are currently exchanging a shared secret is a time you should be exchanging public keys.
Don't worry about "man-in-the-middle" if the alternative is "man anywhere on either side or the middle at any point now or in the future."
-- 'The' Lord and Master Bitman On High, Master Of All
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 for many people).
All that work and in the end you effectively have a single password for everything. Passwords are like testicles in a devil's threeway - you must never let them touch.
Fair point, the password store is a weak point - but not for remote attackers. They need to get the DB, the key file and the password from my head, most of which requires physical access to me. If someone is that determined to get access to my accounts or impersonate me then they could just kidnap me and be done with it.
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 for many people).
All that work and in the end you effectively have a single password for everything.
Passwords are like testicles in a devil's threeway - you must never let them touch.
Fair point, the password store is a weak point - but not for remote attackers. They need to get the DB, the key file and the password from my head, most of which requires physical access to me. If someone is that determined to get access to my accounts or impersonate me then they could just kidnap me and be done with it.
Or be a spurned lover OH WAIT THIS IS SLASHDOT.
Fair point, the password store is a weak point - but not for remote attackers. They need to get the DB, the key file and the password from my head, most of which requires physical access to me. If someone is that determined to get access to my accounts or impersonate me then they could just kidnap me and be done with it.
Or be a spurned lover OH WAIT THIS IS SLASHDOT.
My pycho ex took the direct route of going for me with a large knife and the sharp end of a broken wine bottle. I can tell you that at moments like that you don't care about who might have access to your credentials database!
If somebody has root access to the machine, with actual write access to the software, hashing doesn't matter, because the attacker can do an active attack that gets the raw password that the user types into the login prompt or login web page, before it gets hashed and compared with the stored hash. They can only steal passwords from users who are actually logging in, not from the stored hashes of inactive users, but you're still toast. That's why hashed passwords are obsolete for many applications, and you need to use public-key digital-signature protocols instead - .
Hashing can protect passwords from people who have read access to the password file, which is why the original Unix /etc/passwd didn't need to be protected until a few years of Moore's Law made it easy for password crackers to crack obvious passwords and people grudgingly moved passwords into /etc/shadow (and probably made a few more commands run setuid root that hadn't needed it before.)
Basically, if somebody has access to the password file, and your password is in /usr/dict/words or the OED or is something else obvious, like your dog's name spelled backwards, it doesn't matter if your password hashing algorithm is SHA-256 with a 512-bit salt; if the hash takes much more than a second to calculate on your CPU, it's too annoying to the users, and otherwise the attacker can try a million obvious passwords in a million seconds on a CPU like yours, or in a couple thousand seconds on their GPU farm or PS3.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
If people are sniffing the data between your web servers and you have problems already. If you're using a proper switch, and not a hub, then sniffing actually becomes quite difficult, unless you have access to the wires or the servers themselves. If you're worried about your own employees sniffing passwords, again, you have bigger problems.
Anthropic principle: We see the universe the way it is because if it were different we would not be here to see it.
You guys and your silly passwords.
You don't have your stuff encrypted against your DNA profile?
No wonder your passwords are so easily broken.
Still waiting on Serviscope_minor to wake up to fucking reality and realize that Jessica Price isn't going to fuck him.
the whole thing falls apart.
there might be a big machine manufactured in 1995 that people need to use 30 times a day, but only one person can log on at one time, and logging off/on takes 15 minutes per login... guess what happens? people share passwords because otherwise they couldnt get any work done, but theyd also get fired for having low production numbers on their efficiency reports (because they are standing around all day waiting to logon)
then another vendor decides to outsource their program so now its over the cloud instead of in your company, now your single-sign-on doesnt work anymore, you have 200 employees who now each have 2 passwords instead of 1. and by the way a new timeclock system will now require a 3rd password. and an HR benefits system, a 4th password. voicemail? 5th password. oh and your cafeteria card, 6th password.
what can the IT people do about it? nothing. they dont control what vendors get chosen. they dont control anything really.
So, it introduces a work factor.
Where is the extensive cryptanalysis proving that this does not weaken the result, allowing me to make guesses about the input? And how do you know there aren't any shortcuts to get to the result?
I note that the initial paper is from 1999, a time when MD5 was state of the art.
Excuse me for doubting this scheme without further proof.
Fair point, the password store is a weak point - but not for remote attackers. They need to get the DB, the key file and the password from my head, most of which requires physical access to me. If someone is that determined to get access to my accounts or impersonate me then they could just kidnap me and be done with it.
Or be a spurned lover OH WAIT THIS IS SLASHDOT.
My pycho ex took the direct route of going for me with a large knife and the sharp end of a broken wine bottle. I can tell you that at moments like that you don't care about who might have access to your credentials database!
I consider my nuts part of my credentials database.
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.
This assumes it's "password+salt" -> MD5
Which, yes a hashtable (raindbow table) would be used to get all possible values for a reverse lookup to ALL logins.
Now assume you use the "one-time pad" type of method, ie, something unique per login.
"password+salt+(username)" or "password+salt+(usersignupdate/time)" some unique value that doesn't change, but is different between users, or just store a "randomkey" field that gets generated per user. Sure you could spend 33 hours to crack a password, but you would only get ONE password/login. No rainbowtable possible, no reverse lookup.
Disclaimer: I am not god.
We may not be created equal
But we can be treated equal.