[mrcdima]

But how does one handle password resets without resorting in one form or another to sending some info in plain text to users?

At least one website on the current front page is there because it sent a temporary password in plain text. I assume this happened because the user forgot his password. This says nothing about how they store passwords and after all how else would you handle a password reset? Send a password reset link? That's the same thing.

Sending passwords in plaintext back to the user after he has set/changed his password is clearly a security risk but when it comes to temporary passwords or password resets how else would that info be sent?

[p8952]

You should be sending a token and/or reset link which will allow the user to choose a new password.

This is much better than just sending a new password because:

* It can have a TTL.

* The user has to change it, they can't just keep using the plaintext one forever.

* You can perform some kind of verification, was the request for a new password sent from the same country/IP/device as the person generating a new password.

[mrcdima]

But can't you implement all three with a temporary password as well? Make the password valid for 24 hours only and when the user logs in with their temporary password perform any kind of extra verification and if that's passed then also force the user to change their password. Seems like the same thing.

The website I noticed on the front page (sunsuper.com.au) was doing precisely this (although their TTL was 90 days which is indeed far too long and it's impossible to tell whether they forced a password reset or simply recommended a password change).

[jeltz]

Yes, but using a token is better for usability and trust since that wont make it possible to lock out other users by clicking the forgot password link, and I as a user will think it is more likely someone doing token based resets has done security correctly.