Security issues with friction-less signup flows

I believe this issue affects a lot of applications that have friction-less signup flows i.e. creating accounts without first confirming it via email. This can affect applications in different ways depending upon the functionalities that exist in that application.

For instance, this can lead to a Logical Denial of Service (which is what I will be discussing in this blog), spamming legitimate victim users of activities that they are not aware of, etc.

For the Logical DoS, the attack is actually pretty simple. The only assumption I am going to do here is that username enumeration is possible - which we see is a case for a lot of websites as it is considered by design and a feature provided to aid users:

• An attacker enumerates a legitimate user account email in the vulnerable application. Let’s say this is victim@gmail.com. This of course means that the application uses email addresses as their username.

• The attacker then locks this user’s account by providing the right email and wrong password multiple times.

• The legitimate user tries to login his account by providing his password but cannot login because his account is locked out. Meanwhile, an attacker creates multiple dummy accounts that have email address in the format victim+<id>@gmail.com. Remember there is no email confirmation required for an attacker to confirm the creation of such accounts.

• Now, the victim user obviously has to request password reset since he is locked out. So, he goes ahead and requests one.

• At the same time, the attacker also requests password resets for the multiple accounts that he created i.e. victim+<id>@gmail.com. There is nothing stopping the attacker from doing this. The rate limitation on password reset is a moot point here because the attacker is not requesting the password reset for the same account multiple times. But, instead, he is requesting password resets for multiple different accounts that eventually correspond to the same email address. See the risk of friction-less signup yet?

• All these password reset emails will go to the victim i.e. victim@gmail.com since victim+<id>@gmail.com is the same as victim@gmail.com from an email perspective. An important point to note here is that common email providers like Gmail clubs these emails into one single thread making it even more confusing to determine which email corresponds to which email address. In Gmail particularly, unless one clicks on a small arrow to see the email address, all the emails say To me:

Thus, if there is no clear distinction in the body of these emails as to what account the password-reset email corresponds to, the victim will have a difficult time finding the right password reset link for his original account and will continue to be locked out. This results in a Logical DoS.