Why is “Forgotten Password” bad?

Question

I came across this statement

Do not use "forgotten password" functionality. But if you must, ensure that you are only providing information to the actual user, e.g. by using an email address or challenge question that the legitimate user already provided in the past; do not allow the current user to change this identity information until the correct password has been provided.

Can someone clarify why forgotten passwords are a risk? I plan to handle it by sending the user a link in their email to reset the password, but will not provide them with the old password (since it's hashed anyway), and will not ask them for the old password when resetting. Is there something risky about my approach?

Answer 1

Your approach is absolutely right, as long as you don't store the password.

Asking the security question is absolutely bad instead, as it's prone to be bypassed just by guessing an answer.

Just a little edit: although it may be difficult to catch all of them, you should try to disallow the usage of mailinator email accounts (or email addresses from similar services) because mailinator + forgot password = disaster.

Answer 2

If Charlie can read Alices e-mail, he can also gain access to all sites offering "lost password" functionality.

Answer 3

The most annoying technique would be the following: you click forgot password, are asked for you email and get your own password (which many user use for porn and their online banking ;)) back in plaintext instead of setting a new one.

I would just copy the big players methods, like paypal or google. I think they should now what they do. The most common case should be: forgot password - get a link to your email where you can set a new one or generate a random, secure one (which the user will change back to 1234 immediately).

As we are there already: never return something like "wrong password", as this implies that at least the username exists.

Answer 4

Sending the user a link in an email is actually in compliance with the guidance given.

What it advices against is the practice of allowing users to reset their password without having to have any additional knowledge, i.e. something like a button that will reset the password without forcing the user to click the link in their email. I'm not sure I ever saw such a system, but it is certainly a bad idea =).

Answer 5

Your approach sounds very safe to me :) Ofcourse it should be a one-time link!

Also the "succes" and "email address not found" message/page should be the same. And have an anonymous text.

Like:

"If your mail address is in our system we have send you an email"

In this way, someone will be unable to determine if the email address is in your system or not!

Answer 6

As long as you send the link to the e-mail you have stored on the system then you should be OK - and it's what I'd expect from a system.

I'd also send a confirmation "you have updated your password" to the same address.

Additionally, if the user changes their e-mail address you could consider sending an e-mail to the old address stating that it's been changed to the new one. Slightly annoying perhaps, but it would provide an extra point at which someone could spot if their account has been compromised.

Answer 7

It's rather a sweeping statement and only a bad idea if you don't understand the risks involved and are sure that there is a net benefit (as with most things in life).

You should never store passwords in a recoverable form. Even allowing the customer to store a hint on your system puts the customer at risk. Passwords must always be stored using non-reversible mechanism - i.e. a hash. Given that is the case, you can't recover the customer's old password and send it to them.

Resetting the password on-demand to a random value, then emailing that value to the customer presents the opportunity to carry out denial of service attacks against individual logins (also the case when you disable an account after a number of failed login attempts).

That only leaves the option of generating an alternate login for the customer and emailing it to them - and flagging the account to force the customer to select a new password at next login.

All these approaches delegate the security of the customer account to the customers email system (and all the other email and network components between your server and the customer's inbox) which can, at best be very leaky - certainly its not anything you can provide any guarantees of security over unless you control all of the infrastructure.

C.