With the rise of digital accounts that enable impactful transactions, keeping these accounts secure from unauthorized account takeovers is becoming essential for any online business. With millions of regular users and the ability to spend money or order food, keeping accounts secure is a top priority at DoorDash as well.
To combat these takeovers while still offering convenient credential-based logins, we have opted to use multifactor authentication to ensure accounts are not the target of fraud. The challenge is figuring out how often to ask for MFA credentials only when the situation warrants it, as it can be an obstacle to a frictionless experience. In this post, we will discuss the general problem and how we found a way to optimize MFA for fraudsters while reducing the friction for real users.
The security dangers of credential based logins
Due to the fact that many online accounts ask for credentials, namely usernames and passwords, users are subject to a range of attacks aimed at taking over their accounts. One common way to fraudulently gain access to a user account is with credential stuffing. This is an automated injection of username and password pairs. The logic of these attacks are that many users will reuse usernames and passwords. If credentials are reused on a less secure site, then any leak can make accounts vulnerable on a more secure website.
Preventing unauthorized account takeovers with MFA
In order to protect user accounts, DoorDash built multi-factor authentication (MFA) into the app login process. MFA is where we ask the user for another type of authentication to prove who they are. While credential stuffing can make someone seem like the true owner of a DoorDash account, asking for another form of identification can verify if they are in fact the owner. MFA is one of the strongest protections against account compromise because it’s hard for anyone other than the true owner of an account to have credentials and the second form of verification at the same time.
While it is a powerful tool to prevent fraud, we want to ensure that deploying MFA as an extra layer of protection does not negatively impact our users. Every time someone logs in, we could theoretically ask them to verify their identity with MFA–– but this would add a lot of friction to the online ordering experience and likely turn off customers. Not only is the extra step putting more time between users and making their next order, but poor network connectivity or technical issues can sometimes prevent a good user from accessing their account, which creates a negative user experience. Therefore, we needed to find a way to build a secure yet frictionless way to utilize MFA in the login process. Prioritizing security, we opted for MFA for all, but came up with a framework that exempted MFA from low risk login attempts and continued to optimize the decision engine to reduce more good user frictions.
Providing users with the best experience possible is still important. After we minimized the number of MFA challenges to issue, the next challenge was to ensure MFA code delivery. Users could have trouble passing if they are not able to receive the MFA code or do not receive them in a timely manner. These issues can happen when 3rd party vendors have outages, mobile carriers having network issues cause SMS messages to be delayed or undelivered, or certain mobile carriers inaccurately mark sender phone numbers as spam sender, and block all messages coming from this number. With email delivery, a successful delivery also depends on the recipient’s email server. Many of these factors are out of our control, but we still need a plan when things are not working.
Features that keep user experiences in mind
There are several key features that helped us to achieve our goal of security with minimum impact to user experience. First, an automatic MFA when a login event is deemed suspicious. We built a decision engine that makes the decision based on various signals on the login attempt. For the majority of the user logins, we detect that they are initiated by the owner of the account with high confidence, the MFA challenge then is never issued.
The decision engine utilizes multiple signals which allows fine-tuning of the algorithm over time to exclude even more login attempts as trustable. The second feature is to ensure there are backups. Our initial version of the login MFA uses SMS for code delivery by default with email as backup. MFA code delivery with SMS is familiar to most users. It is also a relatively secure and reliable option and simplifies user flow. The email option enables users to still pass the MFA challenge in case of failure with SMS delivery, which can be a big friction as failure to get the SMS message will effectively lock a good user out of their account. These features are the foundation of login MFA, providing security but ensuring a good user experience.
Multi-Factor Authentication Architecture
A few things on the top of our list to consider when architecting a solution are reusability, reliability, development speed and security. MFA is a very useful common risk challenge that can be applied in other critical events of the user flows in-app. We want to build MFA at login in such a way that the MFA challenge component can be easily reused and integrated with. Therefore we separated the MFA decision engine at login with the MFA service that is only responsible for code generation and verification. Both components are built on existing Risk Platform and the MFA service is a common service that is utilized by many other use cases that triggers MFA challenges. MFA service is built with a highly available in-memory data structure store.
There are several key security features to highlight:
Locking, to make sure only one instance of MFA is activated per user session.
Throttling, throttles requests to prevent spam and attacks and other anti-abuse features, for example, only issues MFA when a user has requested login to prevent an attacker from abusing external endpoints.
Integrating 3rd party SMS and email sender: Building MFA service internally gives us finer control and more flexibility on the MFA decisioning and features, but we chose to use 3rd party services for delivering SMS and email messages, offloading the standard messaging delivery to vendors with this expertise, allowing us to focus more on the MFA business logic. This sped up development time significantly and the messaging vendors provided excellent reliable solutions in terms of message delivery.
Overcoming code delivery challenges
First, we needed to detect the occurrences of SMS and email sending outages and assess the magnitude of the problem. We worked on monitoring and alerting for MFA code delivery and tracked both the number of MFA challenges issued and the number of MFA challenges successfully verified. By tracking these two key metrics, at any moment we are able to detect the current quality of the MFA code delivery. We also integrated 3rd party message delivery status via web hooks, feedback into our monitoring system to detect issues with the 3rd party systems.
Next, we created a mitigation plan for when the codes or any of the third party services were down. Having email as the backup already provides some system resilience should SMS messages degrade. Code delivery is a challenge we continue to work on to improve. For example, based on the insights from the metrics, we noticed MFA messages delivered with a toll-free number having higher error rate based on the deliverability of certain carriers and phones. We were able to improve the error rate by 3% by switching the Toll-free number to a number of 10 Digit Long Code.
Conclusion
With MFA enabled at login, we have built a highly effective protection against account compromise and keeping the friction at minimum. It is always challenging to balance security with usability. What we have built so far is a solution that enables fine tuning in the long term to improve precision on identifying risk during account logins. We also realized login MFA is such a critical feature, that we have spent much of time working on improving reliability and system resilience.
If you are interested in working in creating frictionless, safe and secure ways to access DoorDash’s product and services or building the Identity platform with deep knowledge of our users, please get in touch! The Identity team is hiring, and you can see our open roles here.
