4

How much of a security issue would it be to store temporary / machine generated passwords as clear text in a database?

I understand that passwords should be encrypted using a 1-way hash function with salt. This is especially true for user supplied passwords as users typically re-use them over and over again. If the database was stolen, a thief might be able to gain access to user user accounts on 3rd party websites such as: utility bills, social networks, even potential for online banking.

How much of an issue would it be to store temporary/machine generated "welcome" or "reset" passwords as clear text in a database? The password would be emailed to users and must be changed upon login. The passwords that they supply would then be hashed.

The reason for me asking is that there are a some nice properties to storing a temporary password as clear text. For example, if a user does not get the "welcome" or "reset" email, an admin can quickly look-up their temporary password.

Because the temporary password would be machine generated, if the database was stolen, the thief would not be able to access any 3rd party websites that the users log into. The thief would however be able to login to the application that generated the temporary passwords.

Assigning these passwords a small "expiration" would limit exposure, but overall I am just looking to see how dangerous this approach would be.

dana
  • 14,964
  • 4
  • 53
  • 82
  • 3
    Instead of letting the admin look up the temporary password, allow them to set a new password. It would display it to them, but still store it hashed. – Barmar Oct 11 '13 at 00:26
  • @Bamar - Thanks for the great suggestion. A more secure way to provide similar functionality. – dana Oct 11 '13 at 14:33

2 Answers2

7

You should not store even machine generated passwords in plain text.

Let's see what an attacker can do, if he somehow gains only read access to your database with SQL-injection (i made a small demo how easy SQL-injection can be, just click the next-arrow to get a malicious input).

The attacker with read access, could demand a password reset for any e-mail address he likes. Because he can see the new generated token in the database, he could call the reset page with this token and therefore can change the password of this user. Unnecessary to say, that he can now impersonate the original user.

Handle the token just like every other password, even if it can not be used on other sites. The data accessible by the user-account could contain other data (like birthday, real name), that can be used to hack other sites.

martinstoeckli
  • 21,405
  • 4
  • 52
  • 78
  • 1
    I think I knew this was a bad idea, but was trying to see what I could get away with. Thanks :) – dana Oct 11 '13 at 14:29
  • @martinstoeckli I know it has been awhile but do you happen to have a suggestion for handling password recovery that doesn't have that pitfall? Our CMS used to email users a plaintext password and I upgraded it to use their email address to send them a reset link but the link could be manually recreated by looking at the database. I am not sure how to get around that. – Marie Feb 04 '16 at 19:00
  • @Toni - Reset links usually work with strong random tokens (20 chars). In contrast to weak user passwords, it is absolutely safe to store a fast hash of the token (SHA-256) without salting. This makes the token searchable in the database, you get the token from the request, calculate the hash again and search it in the database. I tried to explain this a bit more detailed in an [article](http://www.martinstoeckli.ch/php/php.html#passwordreset) on my homepage. – martinstoeckli Feb 04 '16 at 19:08
  • Thanks, I understand now. I dont know how I didnt think of that! – Marie Feb 04 '16 at 21:56
5

You absolutely must not store passwords in a database at all, let alone in plain text. You should store hashes of them. See this answer for why. Then you need to build all your password-reset facilities around that fact. See also this answer about password reset features.

Community
  • 1
  • 1
user207421
  • 289,834
  • 37
  • 266
  • 440