Password management of emailed cleartext passwords



  • If a website emails a password in cleartext when you use the "forgot password" function, is there any possibility that the password is hashed? It does generate a different password if you reset it again, but it always gets emailed in cleartext.

    Is it possible to reset a user's password, proceed to email it in cleartext and then hash it? If yes, is this considered to be within good security practice?

    The website does NOT require you to set a new password after you login with the newly created password.



  • "If a website emails a password in cleartext when you use the "forgot password" function, is there any possibility that the password is hashed?"

    Yes, of course. The site might (it actually ought to) store the password in hashed form, and send it to you when it is generated in plain text, then erase it from its memory. The latter is good security practice; sending the actual password in clear text... not so much.

    Is it possible to reset a users password, proceed to email it in cleartext and then hash it? If yes, is this considered to be within good security practice?

    Yes, indeed this is the beginning of a good security practice. But now we have a security token that has been sent to who knows how many systems, that might subsist in uncountable cleartext backups, and even might remain available to anyone with your email password; crack the mailbox, and get access to all the sites.

    So, we...

    One more thing i forgot to add....The website does NOT require you to set a new password after you login with the newly created password.

    ...exactly. So the good security practice is to send a random token (or an URL, which is the same concept), valid only for a short time, not an actual password, in clear text; and use that to create a new password chosen by the user.

    Not changing the password once it's been sent and received and confirmed is definitely a VERY BAD security practice, for it leaves a good password lying around.

    If a new password is chosen by the user, it can be kept hashed on the site and only ever travel from the user's memory to their computer, and to the server through HTTPS - as secure a circuit as feasible.

    some issues (not related to the question itself)

    Token storage

    Someone might be concerned about how to recognize that a token is valid. You needn't necessarily store the token anywhere; you can have the token be self descriptive. Of course, this requires it contains enough information that typing it in might be awkward.

    Example generation:

    date = toBase62(timestamp/60); // 32 bits of timestamp, divided by 60, are about 26 bits, and become five characters. You can use a timestamp starting 2021-01-01 to get smaller numbers that fit in even less bits.
    hash = md5(concat(secret,':',date,':',user); // 32 hex digits
    
    token = concat(user,':',date,':',substr(hash, 8))
    

    The token might now be lserni:a7XzQ:baadf00d. Upon receipt, I can check whether the date lies within the last X hours (otherwise it's invalid), and before that I check that the MD5 of my secret plus date and user does end with 'baadf00d'. Bruteforcing that requires 2^32 attempts, so it's not exactly feasible.

    Denial of service or harassment

    If I know someone's account, I can trigger repeated password resets. They won't go through but the user will receive a lot of emails from the server, which inconveniences both. Also, if I want to prevent them from resetting their password, this works - because they'll receive hundreds of emails, and only one is the one they requested.

    To discourage repeated sending, do not just put a rate limit on outgoing email, because that would allow someone to lock users out of the password reset process. Or if you do, then you must accept any valid token, not just the last one (if you don't do storage, this is an automatic benefit). And even then, you risk that someone who knows the user's password might:

    • send a password reset request, that the user will ignore
    • log in as the user and change the password manually
    • now the user can't reset the password for 24 hours!

    In this case, the trick is to reset the "no-email" safety lockdown time every time someone logs in with the correct password. This could be a time flag associated with the user account. Also, after X email-less password changes, further password changes must be denied unless performed from an email link.

    (All this assumes that the attacker can't change the email address associated to the account, otherwise they can just log in, change the email address, change the password and lock the legitimate owner out. Users could opt-in to a safety measure that will only allow to change the email by sending a secondary token to the current email, which exposes them to some hassle if they lose access to the email - which is why some services provide for a secondary "recovery" email).



Suggested Topics

  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2