Why would you ever want to store a plain-text or encrypted(not hashed) password in a database?

Question

I've heard quite a few reasons for storing hashed passwords in a database. However, there are almost always options in authentications APIs to store passwords as plain text or encrypted.

Is there ever a reason you would want to store a password as plain text or encrypted in a database?

Note To be clear I know that storing non-hashed passwords are almost always bad.(as far as I know anyway) My question is why do most authentication APIs include options to store passwords as encrypted or plain text.

Answer 1

Even if you are quite certain of the security of your database, your users' passwords are still accessible to all administrators.

It is vitally important to understand that password encryption will not protect your website, it can protect your passwords only.

If your website does not have sufficient protection, password encryption will not make it safe from cracking. If your system has been cracked, a hacker can inflict a irreparable damage to it and also gain an access to confidential information, including passwords database. But if you store this information encrypted, hackers practically cannot make use of it. Cracking an encrypted password takes a large amount of time and processing power, even on today's computers.

Answer 2

Maybe you're a hacker, and want to use or sell them?

Answer 3

One reason I can think of is to allow a password recovery option. There's no way to recover a password that the system doesn't know.

Of course the alternative is for the system to just reset the password to something new and send you the new password.

Answer 4

Of course, you could store all passwords as plain text in your storage (e.g. database). But it's not recommended. If someone manages to hack your server and gets your data from the database he also got every password. Even just storing a password hashed with common methods like md5 is not quite save in this case. Because there are rainbow-tables (search google for this), to lookup passwords.

So I recommend to store salted passwords. I don't know why you ever would store your passwords as plain text. I wouldn't do it :)

Answer 5

One reason could be to auto-reuse the password for another, external service.

If i configure my gmail account to retrieve my e-mail from other non-google e-mail provider i have to give google my password and google has to have this password in clear to get my mails into my gmail account.

That is obviously not the same password as for the primary service, but it is "of type password" anyway.

Answer 6

The only real reason I can think of is when the database belongs to a system that is itself targetting the real application. Like when you have programs that log into something for you (email clients, instant messaging clients etc.). All those have to store the password in a recoverable way to get access, because the target application won't decide between real user and user via a tool. Exactly at this point OAuth and alikes however are made to save the user's password.

Answer 7

The only 'good' reason I can think of is that the customer paying you to develop the app or your manager insists on it. I cant think of any technical reasons for it.

Answer 8

1) Most of Challenge-Response authentication protocols require server to know plaintext password. There are exceptions, but they are unpopular and hard to implement.

2) Storing passwords allow password recovery.

Answer 9

I have encountered the following argument a few times:

Storing plaintext passwords allows you to detect when a user changes their password to something close to an old password i.e. by incrementing a number, adding a '1', or by some other low-conditional-entropy updating method.

No one should take that argument as a good reason for storing plaintext passwords - it is misguided for several reasons.