stackoverflow.com

I know PerlMonks is very much more than it's Seekers of Perl Wisdom function, but I think that's what most users originally joined for (and a few stayed for the other community features). Hence much PM traffic went to Stackoverflow.com. Not to mention that even before Stackoverflow, with the lack of momentum for both Perl 5 and 6 and the inexorable rise of PHP, Perl was losing mindshare and hence the monastery was pretty much only for the masters of the deepest Perl secrets and initiates who only had Perl problems because of legacy code.

Anyway, my point is that Jeff Atwood, who co-created Stackoverflow.com wrote several articles about plaintext passwords a long time ago. Then again, someone guessed his admin password for stackoverflow (or was it codinghorror, can't remember).

One thing....

I think there's only limited benefit from hashing (or AES encrypting) password's IF the rest of the user data is stored in an unencrypted format... I mean why protect the key if the data that key is supposed to protect is plain text?

Granted, if the punter is using that password on multiple websites then yes, you are preventing access to that password... but really, any and all "personal" data in the db should be encrypted.

Re: One thing....

Not really.

Given the webserver needs to access that data to perform its actions, then the decryption key would have to be on the server itself, and then once the server is compromised it is only a slight annoyance to the hacker. It would only be beneficial had the database been compromised without the rest of the server, but this would add a performance hit to remedy a marginal case (if your DB engine has a vulnerability severe enough to serve up the entire contents of your database, then full system access is probably not very far behind).

The point of hashing passwords in the way suggested, is that it the hash function is one way, so even the legitimate administrator of the site has no access to the original password, all they have is the result of a hash of the password (and usually some kind of seed text to make dictionary lookups more complicated).

This is because the site never needs to know the cleartext password; all the site need to know is if performing the hash function on the password entered produces the result stored in the database, if it matches, then it grants access.

Re: One Thing ....

"I mean why protect the key if the data that key is supposed to protect is plain text?"

Security is about boundaries and layers.

If I can get read-only access to cleartext passwords, then I can kill your app. If I can get read-only access to properly salted hashes, then I can go soak.

"any and all 'personal' data in the db should be encrypted."

A common problem amongst IT security folk is assuming that every web app should behave like an online banking account.

I am a member of an icon sharing site. I want my password protected so I don't get my social wibblings and connections torched. I don't, however, want the company to spend hundreds of thousands of dollars creating the digital equivalent of fort knox: I want the site to be economically viable.

Correction

The site has reset the passwords of those users whose passwords were publicized by the crackers, not those of all users. While we'd like to have done so for all users, getting the notification emails out to just the more at risk group is proving to be quite a hassle.