Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Temporary Password Security - Storing as Plain Text

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.

like image 594
dana Avatar asked Dec 16 '22 05:12

dana


2 Answers

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.

like image 188
martinstoeckli Avatar answered Dec 28 '22 11:12

martinstoeckli


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.

like image 45
user207421 Avatar answered Dec 28 '22 09:12

user207421