Most account takeovers do not involve anyone breaking encryption. They involve a password that was reused, phished or leaked. The weakness is structural: a password is a secret that two parties hold, so there are two places to steal it from. Making customers choose longer ones does not change that.
Nothing on the Server Worth Stealing
A passkey replaces the shared secret with a pair of keys. The customer's device keeps the private one. Your server stores only the public one, which cannot be used to sign in. Android's documentation states the two consequences that matter to a business: "Passkeys use public-key cryptography so that data breaches of service providers don't result in compromised accounts", and they "are based on industry standard APIs and protocols that are not subject to phishing attacks" (Android).
The first sentence is about your liability. The second is about your support queue.
One Sheet, Both Methods
The practical objection has always been migration: not every customer will have a passkey on day one. Android's Credential Manager removes most of that objection, because a single sign-in request can offer a customer their passkeys and their saved passwords together. The platform requirement is modest. The setup guide asks teams to "target devices running Android 9 (API level 28) or higher" (Android).
Where Projects Go Wrong
The device side is small. The risk is on the server, which issues a one-time challenge and checks the signed answer. The specification leaves no room for shortcuts: "As a cryptographic protocol, Web Authentication is dependent upon randomized challenges to avoid replay attacks" (W3C). Teams should use a maintained server library for that check and not write their own.
The second failure is quieter. If account recovery still hands out access from a single emailed link, recovery is now the easiest way into the account, and that is the route an attacker will take. That is our advice and not a platform rule: recovery has to be at least as strong as sign-in.
Our own article on this subject was rewritten this month. It had quoted a password-reuse statistic with no source and linked two server libraries at addresses that do not exist. Both are corrected.
What to Ask Your Team
- What does our server store that could be used to sign in as a customer? With passkeys the answer is nothing.
- Who verifies the sign-in response, our code or a maintained library?
- Is account recovery weaker than sign-in? If so, it is the real front door.
- What share of sign-ins could move to passkeys this year?
-Rocky
#Authentication #Passkeys #MobileSecurity #EngineeringDreams #StrategiaX
Originally published on ANDROID-ARCHITECT, the Android engineering blog of Strategia-X, with the registration and sign-in code.