During Cybersecurity Awareness Month, Uber is rolling out support for seamless authentication with passkeys on our mobile apps and websites. Use your passkey instead of your password next time you sign in to Uber.
Passkeys are a simpler and more secure alternative to legacy authentication methods like passwords. When a user registers a passkey with a mobile app or website, their device generates a unique cryptographic key pair associated with their account. The public key is stored on the application server, and the private key is stored on their device’s password manager. Next time the user signs into their account, the device needs to be unlocked with a biometric sensor (such as a fingerprint or facial recognition), PIN, or pattern to authorize the passkey.
The primary benefit of passkeys is that they are more resistant to credential stuffing and phishing attacks.
- Traditional login credentials (such as passwords and SMS one-time codes) are stored on the application server to verify the user. Passkeys, on the other hand, leverage public key cryptography and store only the public key on the server. In the event that the server storing the public key is compromised, attackers cannot use the stolen public key to derive the private key stored on a device. Furthermore, each key pair is unique, so credential stuffing and brute force cannot be used to hack into user accounts.
- Passkeys are tied to an application’s identity which makes them more resistant to phishing attacks. Devices can only use a passkey for the mobile app or website it was registered with. This reduces the likelihood that a user will inadvertently share their login credentials with the wrong app or website.
Uber is dedicated to enhancing account security and providing frictionless authentication across all of your devices. Passkeys pave the way toward a passwordless future.
How Do Passkeys Work?
The main entities involved in passkey flows are an authenticator and a relying party. For our purposes, an authenticator refers to a user’s device (e.g., mobile phone, laptop, tablet, etc.) which is responsible for generating cryptographic key pairs, securely managing private keys, and verifying the user. A relying party is an application with a client and server.
The WebAuthn specification, which defines how authenticators and relying parties interact with each other, is standardized across all platforms, so the system architecture is consistent between mobile and desktop devices. As a result, clients can implement cross-device authentication: a passkey created on one device (e.g., an Android device) can be used by another device (e.g., a Windows desktop computer) to authenticate the user.
In the next section, we review passkey registration and authentication flows to understand what data is stored and shared by each entity.
Register a Passkey
Let us break down what is happening behind the scenes of the registration flow.
- The client requests options for credential creation from the server. The requested options include information about the user account and a unique challenge designed to prevent replay attacks.
- The client passes the options response to the authenticator which then shows appropriate UI for the user to provide a biometric or other authorization gesture. After the user creates a passkey, the authenticator generates a new public-private key pair. The authenticator securely stores the private key (typically using a password manager) and returns an attestation statement to the client.
- The client sends the attestation statement to the server, which includes information about the new passkey.
- The server validates that the passkey was generated in a trusted environment, then stores the public key and links it to the user account.
Sign in with a Passkey
Next time you wish to sign in to Uber with your device, you may see an autofill prompt to use your passkey. Otherwise, click the passkey icon next to the form input to initiate login.
Authentication works similarly to registration, but the data shared between entities is different.
- The client requests options for credential assertion from the server. The requested options include a unique challenge designed to prevent replay attacks.
- The client passes these options to the authenticator, which prompts the user to verify their passkey with a biometric or other authorization gesture, then generates and returns an assertion statement.
- The client passes the assertion statement to the server, which includes a signature made with the private key and information about the passkey and its associated user account.
- The server validates the assertion statement then looks up the user’s public key to verify the signature. If the signature is valid, the server assumes that the assertion statement was sent from the same authenticator that generated the passkey. The passkey is considered valid, and the user can proceed to the next step to sign in.
It is important to note that authenticators never share private keys or user authorization data with the relying party. Furthermore, if the public key stored on the relying party’s servers are compromised, the passkey itself is not compromised, since the private key is stored on the authenticator.
Delete a Passkey
At Uber, users are in control of their data, so you can view and delete your passkeys from your Uber account settings anytime. When you delete a passkey from your account, this action only removes the public key from Uber’s servers. Your private key still exists on your device, so you need to delete the passkey from your device’s password manager as well. This is similar to the idea that when you update your password, you also need to update the password in your device’s password manager. But do not worry if you forget to delete the private key from your device–the cryptographic key pair is unusable if both keys are not available.
Last year, Apple, Google, and Microsoft announced a joint effort to expand their support of passkeys on their platforms. Passkey adoption has accelerated since then, but the learning curve to understand passkeys for developers and users alike has been the main challenge of supporting passkeys at Uber.
One of the reasons behind this is that browser and device adoption of passkeys is not yet standardized across the board. Depending on the combination of browser and operating system, device capabilities will vary. The large number of potential use cases to support passkeys greatly increases the technical complexity. This caveat is also confusing for users if some of their devices do not support passkeys. In the future when passkeys are more broadly supported across platforms, there will be fewer edge cases to account for.
Furthermore, we have found it is necessary to develop elegant solutions to help our users bridge the knowledge gap about passkeys. Since passkey adoption is not as widely supported as passwords, users may not understand what passkeys are and thus, they are less inclined to engage with passkey flows. For now, users can fallback to other authentication factors. We anticipate that multiple iterations will be required to perfect the passkey onboarding flow.
As more of our users adopt passkeys, we intend to leverage data about their pain points to improve the experience authenticating with passkeys.
The Future of Authentication is Passkeys
Passkeys offer a simpler and more secure login experience–yet, we have observed that adoption is currently low among users during the initial rollout. Our roadmap to improve the user experience will be based on analysis of the initial data so that we can pinpoint where our users are struggling. For example, the registration flow is buried in the Uber account settings, so we are experimenting with a post-authentication feature to nudge users to create a passkey after they sign in. This feature aims to improve the registration success rate and make the onboarding process more accessible.
Uber is committed to building magical user experiences for passkey authentication and excited to help pave the way toward a passwordless future.
Jenny George is a Frontend Software Engineer focused on growth and reliability initiatives for Uber’s signup and login web platform.
Ryan O Laughlin
Ryan O'Laughlin is a Backend Software Engineer on the Customer Identity Platform team. He works on various efforts to drive growth and improve reliability.
Elan Arulraj is an iOS Senior Software Engineer who works on Uber's signup and login team and has a passion for crafting seamless mobile experiences and bringing unity and simplicity to user accounts on the go.
Joao Pedro Pianta
Joao Pedro Pianta is a Frontend Software Engineer on Uber’s Device Identity team. He develops device authentication and authorization experiences focused on smart devices. He’s based out of Porto Alegre, Brazil.
Jose Alecio Carvalho
José Alécio Carvalho is an Android Senior Software Engineer on Uber’s Device Identity team. He works on projects supporting login and signup across devices and recent efforts on autonomous mobility.
Saurabh Lalwani is an Android Senior Software Engineer on the Customer Identity Platform team.
Cinnamon: Using Century Old Tech to Build a Mean Load Shedder
November 22 / Global
Real-Time Analytics for Mobile App Crashes using Apache Pinot
November 2 / Global
Auto insurance maintained by Uber
CheckEnv: Fast Detection of RPC Calls Between Environments Powered by Graphs
Our Journey Adopting SPIFFE/SPIRE at Scale
Selective Column Reduction for DataLake Storage Cost Efficiency