“John, could you explain what is wrong with doing the hashing client side?”
Im only saying don’t expose algorithms. If you’re using md5 or sha then that’s all well and good. But either way, the more that happens in server scripts like cgi and php the better.
I don’t see any need for javascript except for “interface polishing” as I like to call it. You know, rollovers and alike.
CynicalTyler: thanks for responding. I wrote my post with those views partly to elicit some kind of response.
The uppercasing – it does weaken the password by 2x per letter, but still that’s plenty strong. How are they going to crack someone’s password which is one of (26+10)^8 possible passwords, if it’s hashed? On the other hand, though, you won’t have aggravated users who didn’t realize that the caps lock was on when they put in the password. Is the increase in security so necessary that you would make people remember the case of their password?
Secondly: Yeah, I wondered what was so bad about confirming that a username exists in the system. But I think you’re right – there is no reason we should release that information. So “bad username or password” it is.
Third: No, I simply meant to introduce a tarpit – so you can resubmit a request 1 second later, but you won’t get a response until 5 seconds later. Change the 5 seconds to 2 seconds and you get the point… just put a tarpit there… but I guess yeah it’s unnecessary since you’re cutting it off at n daily tries.
ALSO – the captchas these days can easily be solved, right? There are some good solutions ot prevent spam – but that’s for another post 
Please not ‘nonce’: http://en.wikipedia.org/wiki/Nonce_(slang)
I’m a former plaintext-password-storing web developer. A user called me out on this after a year of operation, and until that point I really didn’t see the problem. It was an “oh-duh” moment.
It’s easy to pick out the websites that do this, since they’re the ones that will offer to e-mail your password to you if you forget it. The ones that only offer a password reset are likely to be adequately encrypting your information.
I’m not a cryptographer either, but when I salt the key, I use a couple lengthy constants of special characters, as well as some other constant data about the user. I can’t imagine a pre-computed table big enough to contain every possible combination of 100 character keys.
I store the SA passwords to our databases on a post-it on the front of my monitor?
Is that incorrect?
It’s unfortunate that sometimes storing passwords as plain text is a contractual requirement from the client because they don’t want to be forced to create a new one when they forget their original password. Sad world we live in.
Or don’t store identity at all: http://identity20.com/media/OSCON2005/
The part you mention about how if somebody obtains a forum password it may be dangerous is very true, in the past I used an exploit in phpBB to gain administrative access to the control panel where I was able to take a backup of the forum and extract the admin’s MD5 and then get it cracked, he was also foolish enough to use this same password as the one for the site’s control panel…actually this happened more than once on a few different sites…but I never did anything malicious to the sites, fortunately for them, I hope they learned that lesson though.
@Brandon: What about black ink?
As I user of many sites I find this helpful:
http://angel.net/~nic/passwdlet.html
Basic premise is this: Use a master password and the service url as salt, then hash it. Since your password is generated at the spot - not even you know what it is (nor should you care).
As far as you are concerned - you only need to remember your master password. The service gets a strong password they can store in plain text if they want.
While we’re on the subject …
And don’t send me the password in my sign-up confirmation email. I know what my password is: Now everyone else can, too.
“Add a long, unique random salt to each password you store”
I still don’t quite get this - if the salt is random, how do we reliably generate the same salt value (For the same user) next time they log in?
After reading your last password blog entry, I’ve been slowly changing my passwords to something a bit more arcane. Upon reading the password requirements for one of my banks, I found that their password rule is that they must be 6-9 case-insensitive letters and/or digits. I emailed them and told them that wasn’t very good. They replied that since their web passwords and phone passwords were the same, that’s the best they could do. They claim to be working on a solution. Mind you, this is a BANK.
Even more scary is that some of the same developers who store passwords in plain text are storing your credit card information.
Years ago, after failing to talk a client out of storing credit card information in the first place, I did a lot of research on how best to secure it - knowing that his hosting environment was going to be, shall we say, inexpensive. Scary stuff, and not a responsibility I wanted.
Every time we code these things we’re betting that no hacker on the planet is a better programmer than we are.
Jeff you should respect the term ‘Hacker’
[I prefer the term: ‘Cracker’ ]
If somebody has access to a password database then
what about the whole directory? Hashing the passwords is
less important than securing the local/web files.
A better solution than using a static salt (or in addition to using a static salt, even better!) is to salt the password using the username (or some the result of some function on it). Otherwise someone could conceivably determine the salt of your website and generate a rainbow table for all your users. If the salt is dependent on the username, a rainbow table is only good for one user.
Cryptography is really a euphemism for competitive paranoia.
The facebook example is interesting: As facebook needs your gmail password to log into gmail on your behalf, it’s no use them storing just a hash of it - they must need (at some point) the plaintext at every login. Obviously the passwords should be encrypted in the database, but I wonder if there’s a smarter solution…?
How do you avoid storing a password in plaintext when a password-recovery-service is required?
a href="http://en.wikipedia.org/wiki/Crypt_"http://en.wikipedia.org/wiki/Crypt_/a(Unix) talks about some salted password system commonly used in UNIX-like systems.
The one currently used in Linux and some of the BSDs is the salted MD5 system mentioned on that page.
As Wikipedia puts it:
"First the passphrase and salt are hashed together, yielding an MD5 message digest. Then a new digest is constructed, hashing together the passphrase, the salt, and the first digest, all in a rather complex form. Then this digest is passed through a thousand iterations of a function which rehashes it together with the passphrase and salt in a manner that varies between rounds. The output of the last of these rounds is the resulting passphrase hash.
The fixed iteration count has caused this scheme to lose the computational expense that it once enjoyed. Variable numbers of rounds are now favoured."
(The article does not explain how you would determine the variable numbers the last sentence refers to).
If you ever look at a hashed unix password that uses this system, it looks something like this: $1$RsDzxp4K$y6ARJtx/TRDYnPWp.3vGy/
Which is broken down as follows:
$1$ = Tells the crypt() system call that this is using the algorithm mentioned above
RsDzxp4K = The salt
$ = salt/password delimiter
y6ARJtx/TRDYnPWp.3vGy/ = password hash
(for the record, the password was “test”)
Since I’ve started as a professional .NET web developer the first thing that gets written is the password page (After the pseudocode and specifications atleast). I’m working on a project now that uses a lot of different security techniques. We’ve put on layers and layers of security. And if we really wanted to we could make it even more secure. But all of that is wasted because the user has to be able to reset their password if they forget it. Which means that either the email or login field has to be unencrypted or easily decrypted in the database. I call this the ‘leaving the key under the garden gnome’ security.
But it will always be a compromise between security and ease of use until their is a better way to store passwords. And a better way to recover credentials if they are lost.
// My facebook habit of adding friends has stopped in its tracks until they offer another method for finding friends. Whatever happened to the email lookup that existed when it was for college alums and students. One thing I’m not doing is opening my address book for anyone.