1

I was recently assessing a web application where during user registration the application would send a password reset link via email where the token portion of the URL was the following in base64:

<Email address>:<randomly generated 12 character password>

When selecting the link the application would log the user in and assign their Authorisation JWT before directing the user to set their own password.

Obviously, there are a few security concerns with this but I wanted to get a better idea of what the impact could be. Could it be assumed that the application is storing passwords in plaintext on the back-end database? It seems somewhat unlikely that the application is generating the random password, sending the password reset email, and then hashing the password and storing it in the database.

Ideally, when a password is set it should be hashed with a non-reversible algorithm and then stored in the database. When a user logs in, the password they provide is hashed and then compared with the hash in storage, dictating whether they authenticate or not.

Improve this question
1
  • 1
    "It seems somewhat unlikely ...." - why do you find this unlikely? There is no technical limitation which prevents proper password hashing in this case, so it is only about speculations. This means answers to this question will primarily be based on opinions not facts. Such questions are considered off-topic here.
    – Steffen Ullrich
    Commented Oct 28, 2021 at 5:27

1 Answer 1

Reset to default
3

Could it be assumed that the application is storing passwords in plaintext on the back-end database? It seems somewhat unlikely that the application is generating the random password, sending the password reset email, and then hashing the password and storing it in the database.

No, you shouldn't assume that. It could be the case, of course, but the "somewhat unlikely" scenario you describe is actually extremely common. It's not like it's hard; you generate the password once, then pass it as a parameter to two different APIs (asynchronous, possibly not even on the same host): one generates and sends the email, the other hashes and stores the password. The code that generated the password forgets it as it goes out of scope. Consider that the same sort of thing happens all the time with "normal" password reset tokens too (which, being password-equivalent, should be hashed in the DB).

Again, this isn't significant evidence either way. It is entirely possible that they are storing passwords - at least the temp password that is automatically assigned - in plain text. But that's pretty unlikely, especially if the generated password can also be used for the standard login flow. People generally understand that passwords need to be salted, these days, even if they don't understand why.

Now, if you use a "forgot password" flow and they send you back the original password, THEN you have reason to believe they're storing plaintext.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .