Great post. I also made one recently about the subject.
Saving passwords in a database? No!
http://jtbworld.blogspot.com/2007/09/saving-passwords-in-database-no.html
@Robert
Excellent post. One other point (perhaps you can add this to your
post): Software developers should never, ever ever email passwords
to users in plaintext.
A year ago I signed up with a website that provides a minor free
service. As soon as I signed up, I received a confirmation email to
the effect of “Thanks for signing up! Your username is ABC, and your
password is DEF.”
I agree with the point you’re making but it would be simple to implement a registration system that emails the user their credentials upon submission and then stores encryped or hashed values into the database for later use.
Just got an email from web 2.0 hopeful Joopz, giving me a free upgrade to premier status for one month, along with a helpful copy of my user name and password from a long ago registration.
We need a hall of shame for these people.
For those who still don’t get it: a salt is not some kind of extra password. The entire world may know what the salt is. The salt is a way to lengthen the user password to such an extend that it will be undoable to create a generic rainbow table up front.
If you use a salt, a cracker will have to build a new rainbow table specially for that salt. I don’t know if anyone ever tried to use brute force to retrieve one of their own passwords, but trust me, it’s a pain, as long as the password is long enough. Building a rainbow table is basically doing brute force, but then you also store every combination you generate, so you can check other hashes with earlier attempts.
Of course, after a while a determined cracker will have generated a rainbow table for a specific salt also, so there the user specific salt comes in. If you choose this user specific salt well enough, a cracker will have use brute force for every single password you stored. Saving the results in a rainbow table is useless now, because the majority of the bits that were used to generate the password hash, are unique per user.
[tinfoil_hat] I guess only the NSA has the capacity and the use for such huge rainbow tables. And trying to fight the NSA isn’t going to attract a lot of users, who, after all, only want to see your fluffy bunny dancing.[/tinfoil_hat]
In short: you don’t need to secure the salt, you only need to make it unique, lengthy and random.
Something I haven’t seen mentioned is row-level encryption of database fields. That protects you from some attacks and not others, of course, and it’s a high-end database feature… but when you have it it makes sense to use it. (And you can always change your database backend code to use it at a higher level - but that’s slow, and an enormous pain to keep synched between backends, especially if you work in several different languages, to say nothing of when you have inline SQL queries.)
As an aside - I’m quite glad that I don’t even know any of my passwords anymore, aside from the one I use for throwaway sites. It’s amazing how well these password hash systems work. (The downside is that it becomes very hard to change passwords short of complicating the scheme more than I’d like.)
When requesting a password reset, the password for cox cable emails is the word password. You would be surprised at the amount of people dont ever change it. When reseting passwords never use a default.
Google’s AuthSub is a nice solution to some of these cross site issues. I found it easy to authorize and import Google Docs without seeing a user’s credentials or resorting to the ‘benevolent phishing’ maneuver.
http://code.google.com/apis/accounts/AuthForWebApps.html
Unfortunately it’s not supported for all of their APIs yet.
I believe you’ve made a cardinal mistake, and in fact, your md5(‘deliciously-salty-’ + password) (md5 can be replaced with SHA-2 or any other hashing algorithm) is vulnerable to the very same rainbow table attack!
With a fixed salt (the ‘deliciously-salty-’) part, one can compute a rainbow table for that algorithm and that salt, and crack any arbitrary password (with the larger the table, the more classes of passwords that you can crack).
The correct way to store passwords is to store two values for each user: a salt (which is a randomly generated string of any length, the longer the better to a point), and hash(salt + password). That way, you cannot compute a rainbow table, and cannot crack the password.
As for the speed of a hashing algorithm being a vulnerability, you may be wrong. The security of the algorithm is the important part. md5 is a technically broken algorithm, and SHA-2 is technically better, but we are talking about security experts here - their idea of broken is different than ours. For all practical purposes, especially in this use case with the combination of random salt, md5 is still secure. See http://en.wikipedia.org/wiki/Md5#Vulnerability
For example, for www.goruneasy.com, I used this md5(random-salt + password) method. The salt is a 10 character string, using characters where each character’s ASCII value is between 1 and 253, creating an incredibly large potential space. I don’t believe, unless a truly massive vulnerability is found in the md5 algorithm, that this approach can be compromised.
It’s too bad there isn’t a generic authority-granting API. Various sites have hand-rolled ones, like Flickr and Facebook itself. For instance, if you want to use the Facebook Firefox extension, it kicks you off to Facebook, where you enter your password on the Facebook site, and then you allow the extension authority. No password ever given to the extension.
The obvious problem with custom APIs is that each provider needs to write one, so if GMail doesn’t have one, you’re screwed. And you need to write custom code to talk to each one, which is no fun either.
For those interested I wrote (read: patched together) a Rails plugin that handles authentication using Coda Hale’s bcrypt library:
This is the way I’ve always felt about a user’s trust online - if it has a pretty layout and stock models appear to enjoy using the website, the user will trust the website with any information it asks for. Sadly, this applies here - people think that FaceBook is some invulnerable application because it’s large, when these are exactly the types of things that are under such great scrutiny.
Salting password is not neccesary, an encryption algorithm like SHA is enough… and offcourse a minimum length for the password.
I gave up reading the conversation since it is essentially the same one we had with Jeff’s last posting on password storage. I know I brought up a couple points which with further reflection turned out to be incorrect (Not sure what I was thinking). No need for details though, since obviously the conversation continues.
The logical and mostly correct outcome of the discussion is good, stored password hash + random salt = good security. Question is, will this design withstand the test of time.
Everyone is aware of the botnets, and the amount of spam being put out, which is almost an entirely seperate issue. I’m just curious if anyone else is scared to death that these botnets could be turned against our authentication systems themselves. You have a generally accepted good security practice, HASH + random salt stored in database, how long do you think this can stand up against a million or more PC botnet?
What is the targetted lifespan of your system?
What if your end user uses the same password for 10 or more years?
I have nothing against a good password scheme, but rule number 1 should always be, don’t give away your database. Your system security architecture should be so good that the “evil” bad guys are unable to obtain your database from forgetten backups and all the other methods. The true reason we need to secure the passwords in the database, is we’re not sure we can keep the data safe, and it’s also very easy to implement rudimentry protection, that as it stands can discourage your script kiddies.
Rudimentry protection will not always be enough.
woops, my apologies. I didn’t knew my first try got trough already. Please remove the first try (and this reply)…
Yes, this very issue started with me when Word 2007 came out with its clear-text-password Blog-posting feature. Sad.
It’s pretty spectacular how nobody really understands salts.
The point, people, is so that you can invalidate pre computed hash values (rainbow tables) by pre-pending a constant but random string in front of your password. It doesn’t have to be hidden, it doesn’t have to be random each time. It just needs to be somewhat longer than the clear texts used to create rainbow tables. If a user has a ‘password’ for a password, cracking it will take the duration of a a seek and scan in a DVD full of precomputed hashes. If a user has 128 bytes of garbage + ‘password’ as their password, chances are the DVD won’t have the answer.
I wonder if anyone reads this far down. I know I didn’t…
Depending on what you actually want to do with the password, you may have to store it in plain-text. Most CHAP implementations require this, for instance. What does using CHAP get you? You’re not asking the client to send his secret over the wire. This is obviously a good thing. Other examples of security protocols that depend on both parties sharing a known secret (e.g. a password/username pair) with similar characteristics can be easily found.
For web development – in particular, for implementations of a classic web “login” service – here are some symptoms that may indicate that you probably need a plain-text password somewhere:
*) One of your requirements is to offer a “password recovery” feature
*) The secret is going to be re-used for other types of authentication (think “Single Sign-On”) that require plain-text secrets
*) The secret may need to be shared with other partners who are unwilling or unable to deal with using your authentication service
Salting password is not necessary
Given the information presented so far in this thread, you’re right. So far, salts have been discussed as a mechanism for making the password longer, as a way to defeat rainbow tables (and brute force, for that matter). In this perspective, salts buy you nothing that a longer passphrase wouldn’t buy (except possibly somewhat higher entropy).
The real reason for using salts is not as a password extender (that can be solved with longer passwords) - it is as a password mutator.
The reason that salts are used is that users reuse their passwords between systems. If I crack your password on one site (finding an input string that produces the same hash) I can now log in as you on all other sites that use the same hashing function and where you have used the same password. Unless, that is, the password has been salted differently on all those different sites. Then I could only log in to those other sites as you if I actually have your plain text password, which is not what I get by cracking a hashed password.
Thus, you could acheive the real purpose of having a salt by using the salt value to mutate the password in some way without even making it longer. You could even make the password shorter. The important part is that, even if I use the same password on all sites, my password will be mutated differently on all sites, so that someone who has found a string that results in my hash on one system won’t be able to reuse it on another system.
Of course, mutating the the password so that it becomes shorter would have the negative side effect of making the password easier to crack, so that is obviously not the suggested approach. Correspondingly, if you mutate the password in such a way as to make it longer, you make it a little harder to crack as a bonus. But this is a bonus, and /not/ the primary reason salts are used.
I’ve just written a blog post trying to explain this difference and why, in my opinion, storing passwords in plain text should be illegal.
a href="http://www.matshelander.com/wordpress/?p=73"http://www.matshelander.com/wordpress/?p=73/a
/Mats
Appending (as is my habit…)
This perspective (salts are primarily for mutation rather than extension) also allows you to understand why early salts were often pretty short.
It is not the case that the makers of those early systems thought a couple-of-bytes salt would be enough to /extend/ the password in a meaningful way, making it more immune against brute-force attacks. Instead, they correctly recognized that it would be enough mutation to serve the primary purpose of using a salt as a mutator, preventing reuse of hacked passwords between systems.
Since then, salts have grown as this allows the secondary bi-effect of making the passwords longer and harder to crack to be exploited - which is, of course, all fine and good.
The problem comes when the primary purpose is forgotten and someone correctly observes that using longer passwords would then make salts unecessary - that’s true with regards to the secondary effect of making passwords longer, but it is not true with regards to mutating passwords between systems.
/Mats