One reason that applies to big business is that you may not want people who have access to the DB to have access to the passwords of others, but even still if you have someone with legit access to your DB and you can't trust them you have issues anyway.

I have been in arguments about this before and I am all for changing my mind when I see the error in my thinking but I haven't been given a good reason for it yet. I don't see why password encrypting on secure databases is better then not.

All encrypting does is makes it harder for someone who gets in to get passwords, but it isn't going to stop someone. If a "bad" person gets access to your DB/server you are in trouble.

I guess you could tout it as a feature to give people the "warm and fuzzies" but that is all it is good for IMO.

[edited by: Demaestro at 6:37 pm (utc) on April 2, 2008]

A hacker may be able to maliciously make everyone's account useless by changing the password to giberish, but they won't be able to change the password to something they will be able to use. Don't use hash. Use a real encryption method that requires a seed. That way they won't be able to know how to substitute the passwords, just delete them or make them useless.

Further, a hacker may delete passwords to be malicious, but more insidious is a hacker who has compromised your database, but is smart enough not to raise any flags and can pull compromised data from you for months/years.

stajer,

I don't get what you mean. If a hacker can execute SQL on your DB how does encrypted passwords do anything to help?

They already have access to the DB so the damage is done. If they can delete your password they can look up any data they want on you and it doesn't matter if they can log in as that person they can just execute queries and get/change the same account info as if they logged in.

Wouldn't it be better to focus on securing your server then encrypting passwords? If your DB is secure you don't need to encrypt any data... if you think your server is available to hackers then you should just encrypt every field not just the password one.

[edited by: Demaestro at 6:44 pm (utc) on April 2, 2008]

Your users will appreciate that people who can (legally) read the database info will not be able to so easily know their passwords. Many people use the same password for different things so just having them stored in the clear is an issue.
Also, I think it is a problem if they can just use the password as opposed to needing to change it or mess with the db 'by hand'. Take a bank for example. If someone could easily see my password they could sit back, have a cup of coffee (or write a script) and withdraw $23.50 from my account every month for the next 2 years .. I might not even notice. But if they had to change the password I'd notice. If they had to muck around with the database in an ad-hoc way the bank might notice. And if they could easily read my password and also log into my credit card account (I use a different password but I digress ;) ) then that would not be so great.
I agree securing your server is also important, but encrypting passwords in a database is just another layer of security you should implement.

The reused password is the only good reason I have heard for using encrypted passwords. I have heard this reason before, it has merit as a reason that is for sure, since i know my ethics I don't even worry about that but in larger companies this is compelling.

but...

If you have an unscrupulous employee I don't see it helping, just slowing it down or as you stated it makes it harder but with time and energy an unscrupulous employee will find a way to do bad if they have their mind set on it.

just slowing it down or as you stated it makes it harder

True. But I still lock the doors when I go to sleep at night even though I know someone can just smash the window ;)

One of the reasons I brought this whole question up is the fact that I have to write a script that will email someone their password if they forget it. Hashing a password makes that near impossible, and I've yet to find a simple method of encrypting a password to go into the DB and then decrypting it to send back to the user.

I guess since I'm the only one who views the database it's somewhat of a moot point, since the only person I have to trust with the information is myself. I just don't want to go through all of the trouble of implementing or creating some sort of cipher when, like Demaestro says, if someone gets into your database they pretty much have you by the balls anyway.

I just kind of wish that MySQL had some sort of way to star out something placed in a special field type but still read the contents, like the password input type. I realize that is more a browser thing than a DB thing, but it'd be nice.

physics, good point about the door. I guess sometimes making it harder is enough to discourage... and it does give what I call "The warm and fuzzies" which is a real thing and matters to real clients. If someone is convinced that doing something will matter even if it doesn't i just do it and they get that warm and fuzzy feeling inside that all is well. That is a good thing.

Murdoch, you should be ok with the decrypted passwords in your DB.

A whole new cans of worms is opened though when you decide to email a password in plain text.

How secure is the email server that gets the password?
Is it a shared email account?
Is it the correct email account?

Way more issues to think about when emailing passwords. I won't say don't do it, but I will say be careful. Make sure all accounts have a "confirm email address" feature, don't email passwords to accounts where the email is not confirmed.... ok actually don't do it.

Just email them a temp login that expires in 30 minutes and lets them set a new password.

Databases aren't just stored in memory. Your database exists on disk(s). For any even minorly important application, it likely also exists in multiple backups locations/media.

Someone doesn't need to have SQL access to your database to read the plain-text passwords that will then give them access to do things on your system they shouldn't.

Generally speaking, if someone "loses" their password, the ideal solution is a one-time use link emailed to them that allows them to reset their password. The not-as-ideal solution is to have the system create them a new random password and email it to them with instructions to log in using it and then immediately change their password.

Generally speaking, if someone "loses" their password, the ideal solution is a one-time use link emailed to them that allows them to reset their password.

I think this is the idea I may go with. That way if the link in the email is clicked it will let the user change the password and if not, then nothing is affected. This is just as safe or unsafe as sending them the plain text password through an email anyway. Thanks for that.

The not-as-ideal solution is to have the system create them a new random password and email it to them with instructions to log in using it and then immediately change their password.

I could see this being abused by people who don't like another person and knows their email, making them change their password every day. I guess that's why you called it the not-so-ideal solution :)

Thanks again
-Doc