With user-password authentication, it is common for users to try and log in with an email address they though they’d signed up with, but didn’t.
Upon failing password verification, they then recover their password to the same email address they tried to log in with. They get told a password reset email will arrive. As expected, it never arrives.
Now it is understandable that Auth0 doesn’t display a message saying “No such account”, as that would let hackers know which accounts do and don’t exist.
However login dialogs typically say “A password reset email has been sent IF such an account exists.”
I haven’t been able to find a way to customize this message for when a password belonging to a non-existing account is trying to be recovered. Not being big enough to worry about hackers yet, our users are finding this frustrating.
With regards to the message that Lock displays when a reset password process is initiated with success you can tweak it to contain the clause you mentioned or something similar; check the reference documentation for Lock I18N support.
tries login with new jp@abc.com and reset password
login fails
In my experience, an email is sent even IF the account does not exist.
**How can we prevent the email from sending if the email does not exist? ** Is there a setting I’m missing?
The referenced link was helpful Thank you jmangelo. I’ll try passing in a different forgotPasswordInstructions option (found it in lock/en.js at master · auth0/lock · GitHub) on lock initialization.
If that doesn’t work I’ll host my own en.js (as I’m using Xamarin’s Auth0.dll).
I haven’t received the email yet after doing a password recovery on an account that doesn’t exist. Maybe has been 10-15 minutes since I requested it.
I did however receive a password recovery email for a different email account that belong to a signup I did through Facebook though - which I thought was a bit strange as I can’t change my FB password through Auth0.
The referenced link was helpful Thank you jmangelo. I’ll try passing in a different forgotPasswordInstructions option (found it in lock/en.js at master · auth0/lock · GitHub) on lock initialization.
If that doesn’t work I’ll host my own en.js (as I’m using Xamarin’s Auth0.dll).
I haven’t received the email yet after doing a password recovery on an account that doesn’t exist. Maybe has been 10-15 minutes since I requested it.
I did however receive a password recovery email for a different email account that belong to a signup I did through Facebook though - which I thought was a bit strange as I can’t change my FB password through Auth0.
@simon2 and @josh1 the expected behavior would be that Lock (underlying API) does not technically expose the fact that the email is associated with a valid account or not, but then an email should only be sent if a valid account exists. In addition, I would exclude FB (and alike) accounts because like mentioned their passwords are managed elsewhere. @josh1 can you confirm that you’re receiving an email even when there is absolute no trace of that email in any account and @simon2 can you confirm that the email was only associated with FB and was also not present in a database account.
From a quick look you would want to change success.forgotPassword message to phrase it in a way that includes a clause to say the email is only sent if the account exists. However, after my suggestion you mentioned a different issue about emails being sent always so that needs to be reviewed separately.
Agree with the expected behavior - that it doesn’t expose if an account exists or not. I just needed to make the legitimate user aware that he won’t get an email if he hadn’t already signed up - just a slight tweaking of wording.
I’m confident that the email address that received a recovery email only existed as a facebook| login, but I doubly confirm during the day and try recovering again.
@jmangelo Auth0 signup API reports an error if you try to create an account with an email address that is already used. Given account existence is already exposed via the signup API, why try to hide it in the password reset api?
The reality is that the public signup endpoint disclosing that information is an issue already being tracked; however, you can more easily avoid getting in that situation then the one in the reset password. In particular, you can disable the Auth0 service public signup endpoint and do signups from your own backed through the management API. This is fairly simple to accomplish when compared to implementing your own reset password mechanism. In conclusion, probably both endpoints should not have any issues by default, but the reset password is more important.
The user who reported no email was being received upon password recovery wasn’t a signed up account, so I would say not. That is what I believe to be the correct course of action too.