eBay’s Journey to Passwordless with FIDO

We recently published a case study in partnership with FIDO Alliance. We have been working on our authentication journey for the last ~2 years. We still have ways to go but wanted to share more details on our progress so far as well as our experience and learnings. Anand and I have shared parts of this at Identiverse 2020, Authenticate 2020 and Know Identity Forum. This is an attempt to add a bit more color.

Our underlying problem statement is the same as most sites today - Passwords are bad. Results in fraud, account take over (ATO), additional support calls, user abandonment etc. Existing 2FA methods helps with security at the cost of experience and results in:

• Limited Adoption: You can only move the needle so much with the security message.
• Lower sign-in completion rate (attempt vs success): Impacts overall conversion numbers for the business.

If you have limited time, here are our high level takeaways:

• Each auth method has its pros/cons. It’s unlikely a single auth method will serve your needs. Most of us have a diverse customer base. You would need to support more than one.
• WebAuthn/UAF does a great job in balancing security and usability. It’s not completely there yet but we are close.
• For each auth method you support, remember to think through a) enrollment, b) sign-in and c) account recovery flows.

I know there has been a lot of debate recently against SMS as a strong auth method. I have a slightly contrarian view on the topic. Most people compare it with other strong auth methods (device biometric, security keys etc). I agree that compared to other strong auth methods, it’s less preferred. However, it still offers more security than password by itself, supports an experience that most users now understand and does a good job of handling the long tail.

Our thought process has been to start building capabilities and support multiple ways to securely access your account and let users pick what works best for them. One of the important metrics is reducing the number of users who are protecting their accounts via passwords only.

In addition to Password/SMS flow, we now support 3 additional strong auth methods

• Password/Push Notification via UAF
• WebAuthn/Platform Authenticators
• WebAuthn/Roaming Authenticators / Security Keys

I’ll walk through more details for each of the methods. Each of these flows are live and in production. You can always skip the article and go straight to eBay.com. There is no better way to experience a feature than try it.

1. Password/Push Notification via UAF:

We support this as a 2FA option i.e. you need a password and push notification to access the account. Compared to SMS, I believe it offers a) cheaper b) secure and c) better experience. We used FIDO/UAF to enable the option. We built our own protocol handler and open sourced it.

Enrollment: Download eBay App. Go to My eBay → Settings → Sign in and Security. Turn-on 2 step verification. It will make sure you have a verified phone number on file.

Sign-In: Go to eBay.com. Enter username/password. A notification will go to your device. Approve and you are in.

Recovery: You can recover by entering password and SMS.

2. WebAuthn/Platform Authenticator

We have been happy with the adoption as well as completion rates for this flow. Sign-in completion rate is better than password (especially on mobile)…which is a big win. I strongly believe this (or app authenticator) to become the most popular auth method in future for consumer sites.

Enrollment: Go to eBay.com. Sign-in using existing credentials. If your OS/browser supports WebAuthn, we’ll detect it and show a pop-up to enroll. Once you enroll, it will become the default option for subsequent access on that device.

Sign-In: Go to eBay.com. Click Sign In. Your login screen will now show login via biometrics flow. Do a fingerprint/Face biometric check and you are in.

Recovery: Since we are currently offering this as an alternative to password (and not augmenting it), you can recover it using your usual methods. Our current focus has been to get the adoption and experience right. Eventually we’ll build a stronger recovery flow. 

3. Security Keys

Even though this requires carrying an additional device (and costs money), it has the benefit of working across devices and across services. This also makes a good backup recovery option.

Enrollment: Go to eBay.com. Sign-in using existing credentials. Go to Settings→ Sign in and Security and turn on ‘Security Key Sign-in’. Assuming your OS/browser supports it, you get to select a PIN and enroll.

Sign-In: Go to eBay.com. If you have enrolled in Security Key and your OS/browser supports it, you will see an option ‘Sign In with Security Key”. Once you select that option to login, it becomes the default option for this device. 

Recovery: An area that we need some more work but you can enroll in any of the other methods (password/SMS, Push / WebAuthn etc) for recovery.

Here is a high level timeline of our progress:

• UAF - Push Notification: May 2019
• WebAuthn(Platform) - Android/Chrome: Oct 2019
• WebAuthn(Platform) - Mac/Chrome: Mar 2020
• WebAuthn (Roaming) - Security Key: Oct 2020
• WebAuthn (Platform) - Win/Chrome: Nov 2020
• WebAuthn (Platform) - Win/Edge: Jan 2021
• WebAuthn (Platform) - iOS/Safari: Feb 2021

Learnings/Challenges

Here are a few learnings / challenges we came across during our deployments. 

• Different experience across browsers / platforms: We need consistency in content, size of popup window, background color, button labels etc. For example, the text to address the user in the system dialog is different on MacOS and Windows. Latter honors the values passed in the javascript request and addresses the user with their name/email while the former ignores it. We struggled whether to call it fingerprint or TouchID or biometric in our prompts. IMO the different experience across platforms shown below doesn’t cut it.

• Inconsistent implementation of the spec across platforms (Safari 14): Safari on Mac/iOS platforms mandates propagation of user gesture from user activate events while that is not part of the spec and for the most part breaks if not taken care specifically. More details here:  
• Detection of Biometric vs PIN: WebAuthN specification provides an API to detect if a device/browser is capable of user-verifying platform authentication via PublicKeyCredential.isUserVerifyingPlatformAuthenticatorAvailable. Similar functionality is not there to check for user-verifying roaming authenticator. 
• Testing Matrix / Automated Testing: Automating end to end user interaction flows to test various platform and roaming authenticators is not possible today. This slows down the development and release cycle as we rely heavily on manual testing.  
• Support for multiple Top level domain (TLD): Specification does not support multiple TLD for the same relying party. Credentials registered for the same user on ebay.com will not be allowed/accepted at ebay.co.uk. Also, there is no specification support for vendors/platforms to implement it. 
• Limited platform support for roaming authenticators: In our testing we found out that majority of the browsers support roaming authenticators. However not many support the user verification and presence enabled roaming authenticators.
• Lack of clear documentation on platforms /browser versions that support CTAP2 protocol (Key + PIN): A common publicly accessible place to find compatibility matrix is missing. This affects a relying party from offering the functionality in general to all platforms. We decided to go with the whitelisting approach to have a phased and tested rolled out.
• Account Recovery challenges: This is a stickler. Current recommendations I have seen are a) take a printout of security codes and keep in a safe place b) enroll multiple devices or c) Call support. I don’t believe any of them are practical for mass adoption. As of now, secure code via email or phone (augmented with device profiling) is probably the best you can do for the long tail. Going forward, I can see ID verification as a way to account recovery without adding additional friction during enrollment time. 

I have been asked multiple times “What do you see as our biggest challenge to industry adoption of FIDO authentication and what are few things we should do as an industry to overcome those challenges?” I believe we have come a long way. Even though there are a few issues to be worked out, the protocol is mature enough for deployment. Here is what I see as the challenges/recommendations:

1. User Awareness: In spite of several industry efforts, it’s appealing primarily to tech savvy users. I shared this earlier that we have just implemented Apple Sign-in. There are now 3 ways you can login to eBay using FaceID. We have to support all of them. We have to maintain all of them….and we have to explain all of them to our users. We need to simplify and clarify. The user awareness campaign shouldn’t be by relying parties or vendors but driven by platform vendors - Google, Apple, Microsoft, Samsung...and driven as a collective campaign. It should not be about Microsoft Hello or Apple Sign-in or Google Smart Lock but rather using your device as a means to authenticate - a cross-device, cross-platform capability. 
2. Consistency: Consistency across platforms (as shared in the challenges section above) as well as consistency across relying parties. The experience for an end user at eBay should be similar to the experience at Wells Fargo...and similar at AirBnb. I have shared this before that I believe enrollment in #FIDO should be as simple and consistent as connecting with Wifi or Bluetooth. As of now, there are no blueprints or guidelines for relying parties. We have been open and transparent in sharing our experiences and hoping we continue to collaborate on best practices. 

Overall, this is still a work in progress. Looking forward to collaborating with others and moving the needle for a better authentication future.