4

I recently found out that a website I use every day let me know my hashed password.

The process was the following :

  • Go to "Delete account" and enter your password. Password is checked.
  • If password is correct, a form then appear where you have to set why you are deleting your account (at this moment, the account is not yet deleted). There is an hidden input called hashedPassword containing what I think is my hashed password.
  • When you valid the form, your account is deleted.

Since you first have to input your password to get the hashed password, I don't directly consider it a vulnerability. This process doesn't look dangerous to me, even if I was a little bit surprise to see my hashed password.

All I can see is that it might allows the user to discover the hashing algorithm, or even let you find the salt used.

Is this a bad practice ? Is it dangerous and how could it be used by an attacker usefully ?

Improve this question
3
  • 8
    What concerns me more is not the hashed password being exposed but the reason it's being exposed - are they using that hidden field as some sort of authentication of the subsequent deletion request? If so, does that mean it can be leveraged to perform other actions under the hood?
    – gowenfawr
    Aug 15, 2017 at 3:29
  • @gowenfawr As far as I see, the account is not being deleted if the hash is not valid. I guess it is badly coded, and instead of storing a a variable server side after password check, they simply send back the hashed password.
    – Xavier59
    Aug 15, 2017 at 19:36
  • 2
    I'm wondering if they expose the hashes elsewhere on the site. It's possible the regular login forms do client-side hashing, which would be bad.
    – Jeremy Kato
    Aug 15, 2017 at 20:22

2 Answers 2

Reset to default
6

It seems needless exposure to me. Hopefully it is not merely hashed, but with a sizeable random per-user salt and a KDF with a lot of iterations. Even so, the intent of the design is to keep it protected on the server, not to send it out to clients.

If as you say, the hidden field is sent out of the server only upon proper authentication, the risk is far lesser (so a hacker wouldn't easily be able to collect hashes by attempting to reset a whole bunch of users' passwords), but it still appears needless.

The reason we are still talking about risk is that end-user systems and networks are far easier to snoop on, than consciously secured servers. So if in this case an attacker has a privileged position on a network that uses SSL stripping at its perimeter, then (s)he wouldn't need to "hack the server" - thus bypassing server-side protections.

We could argue that "the user account is going to be deleted anyway", and to some extent it would be true (lower risk). Still, a cache of used passwords (if they can be derived from the hashes) is nice to have - since password reuse is rampant.

Improve this answer
0

The way you've described it above, this is probably bad practice. Your web browser should not need to hold onto your password (or your hashed password) after the first authentication. The standard approach is to use token-based authentication, where you authenticate once and then the server returns an authentication token to your machine that does not include your account or your password in any way.

https://stackoverflow.com/questions/1592534/what-is-token-based-authentication

In this case the main benefit is that the password or it's hash is not floating around any longer than necessary. The server should return a token to your machine that gives you permission to delete your account after you complete the second form.

Improve this answer

You must log in to answer this question.

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