db password hashes

This is on my to-do-list. Either this will be a sitewide option or switchable for each user, I’m not sure about that point. But don’t nail me on any timeline, unfortunately I’m quite busy at the moment ??
Bye, Mike

There’s a sort of backwards md5 functionality, in case you didn’t know….
The password is still stored in the db in plaintext. But you can enter your password as ‘md5:[hashvalue]’ (e.g. ‘md5:08023c5e326c8682858dd3652535b397’) in the login form, and the plaintext won’t get sent over the wire or stored in your login cookie.

Why aren’t the passwords stored in the database hashed with MD5 or SHA? Would make sense to do that.

There has been comments that plaintext passwords can be useful to restore your password after you lost it. Instead of generating a new one you can easily retrieve and reuse your old one. On the other hand there are good reasons for having secure password storage.
While we are at it, I’d like to hear your (all attending readers) opinion: would you prefer to have this as a personal option (each user may decide if (s)he uses encrypted passwords or not), or should it be a sitewide option?

I’d rather have it be a sitewide option.

Just to mention that: the sitewide option won’t have an easy way backwards. Once the admin decided to use encrypted passwords (which could also happen as an upgrade to already installed blogs) you can’t just switch back to unencrypted passwords. As there is no way to retrieve the old passwords, new passwords had to be created for every user…

I recommend testing the crap out of it before you put it in production code … we didn’t do that with the MD5 hashing code in Greymatter back in the day and looked like a bunch of fools. ??

Could you please give me a hint where I find more about that issue that you speak of? I’m not aware what happened with Greymatter regarding MD5…

Hey .. I’m new to wordpress, but honestly … this is a bit scary. And the fact that encrypting passwords in the database is up for debate is … scary in and of itself.
Two reasons for encrypting:
1) The scary possibility someone might get access to the database
2) The privacy of users. We all know you have to be EXTRA careful about choosing random passwords when I sign up on OTHER people’s sites … but I’d feel a lot more comfortable if the admin of the site COULDN’T get access to my password.
Of course, what you have to do is require valid emails for all accounts, so if people forget their password, you have a (fairly) safe way to give them a new one without worrying (too much) about someone intercepting it.
As a side note, the database login password is out in the open in a .php file, so if they can get un-pre-processed access to that, they have complete access to the back-end database …

Mike … the forums from that time are just about kaput, so I can’t point you to the discussion … and it’s been a couple years, so I’m pretty hazy.
I’ll talk to a couple of the people involved at the time and see if we can dredge up the memories.
FWIW, the people now developing GM have an encryption system that’s working for them; you might chat with them and see what they’re doing.
GFM <– no longer involved with GM at all

Seems like it should be an admin option and not a user option. The admin is the one who really has to care when it comes right down to it. I’d like to see it just be hashed, no questions asked, but give the admin the choice as there are surely those who will complain. I’d also suggest that new sites default to hashed and updated sites keep it as it until told differently. Perhaps in the install, give the option to change with an explanation as to why. The WP developers would look bad if someone decided to have a spree of searching plaintext passwords from WP and suddently WP sights started getting cracked all over the place.

No real reason people need to have unencrypted passwords. Someone forgets theirs, fine, hash a random one and email it to them; even can be implemented in the UI fairly easily. Sounds like far more work for you guys to implement a dual use system than just to wrap md5( ) around the code on registration, login password submission, and the db query.
When you do the next upgrade where you implement the service, just add a quick n-dirty hasher that will encrypt the passwords in the db. Or on password checks, have it test both the hashed and unhashed version, but force all new registrations to be hashed. That’s what I did in a little site of mine, and it’s worked fine.

*bump* All hashes, all the time, no need for options, simply generate a random password and let the user change it when they lose theirs. Simply add plaintext->md5 to the upgrade script. Simply use md5($password) to do it, very little code work needs to be done.
That thing about sending your password as md5:blah is a little silly, isn’t it? If someone intercepts that, it’s just as useful to them as intercepting the real password. Unless, of course, you use the same password over an unencrypted form that you use to secure sentitive encrypted information. If so…well, you shouldn’t.

I agree that passwords needs to be stored as hashes. It’s very standard practice on the web now not to be able to get your password back, but to have to recieve a new one at your registered e-mail address. Only sane way to do it IMHO and something important to have done before 1.0 so as not to look silly ??

I strongly agree with Sisob, Zeno, and Jaykul. WordPress has so many good features offer, but storing cleartext passwords is an awfully big risk to carry, especially when WP is hosted on a shared server–which unfortunately is what the vast majority of personal site do use. Unfortunately, password hashing didn’t make it into the 1.0 release after all. Too many people use the same login/password combo all the other the net, so a compromise of one site’s user db can have a nasty domino effect for the user whose password has been exposed. Hopefully the developers will add mandatory password hashing very soon. There’s good reason this has become such a routine security/privacy measure.