A very common security best practice is to avoid information leakage on web sites. This basically means you shouldn’t be able to figure out if a user account exists, by just simply typing in an email address into a website and interpreting the response.
This is achieved by not disclosing whether “your email or your password was incorrect” when logging in and by responding with “if this email exists, we will send an reset password link” when you forget your password. In both cases you can’t find out if the email address exists in their system.
Or can you?
Most of us receive emails almost instantaneously on our private (or maybe even on the business) phone. Let’s say you’re within hearing or seeing distance of the potential beard groomer that you’re targeting. Enter their email address into the forgot password field and wait for the “ding” on their phone. Now you can be pretty sure they just received that reset password link and you’ve uncovered their beard secret.
Of course this requires knowing their email address. But how hard is to guess your own private email address? Try firstname.lastname@gmail/hotmail.com and you’re probably good to go.
Another scenario often seen is sending the user an email if too many invalid login attempts have occurred (and subsequently the account is now locked). What was meant to increase security (the automatic lock out) again leaks information indirectly via the email.
The core of the problem lies in the coupling between the secret event and the notification at a known destination.
How can we mitigate this?
The lock out scenario is fairly simple. Don’t send an email when the locking occurs, but rather tell the user you are going to send a reset link when the user next logs on with the correct credentials (and provide the option to postpone sending).
The forgot password is a bit harder. Here security will come at the cost of some usability. The idea again is to separate the event causing the email and the actual sending of the email. If you wait a random number of minutes (>15) before sending the email then the attacker can’t be sure the email is related.
As a final note, this scenario can be extended to private message notifications. If the attacker creates a fake account, reduces the number of potential accounts belonging to the victim (usually by knowing some information such as location, age etc) and just sends a private message to each one, chances are that he will hit the victim’s account sooner or later and “ding”. The beard groomer is uncovered once again.