Look at your users table.
There is probably a column
called password hash.
It is probably not nullable.
And somewhere in the login flow
there is a step
that compares it.
That shape is starting to age.
In May 2022
Apple, Google and Microsoft
announced together
that they would support passkeys
across their platforms.
They do now.
A passkey is a key pair.
The private half
stays on the person's device,
or in their platform's password manager,
synced between their devices.
Your server keeps only the public half.
Signing in
is the device signing a challenge
your server just made up.
Nothing secret
ever crosses the wire.
And the key is bound
to your site's domain,
so a perfect copy of your login page
on a lookalike address
gets nothing to work with.
Phishing loses
its main way in.
A leaked database
leaks public keys,
which are no use to anyone.
More of your users
are going to arrive
with one of these
and no wish to make a password.
Ask what your code assumes.
Can an account exist
with no password at all?
Can one person have
several passkeys,
for a phone, a laptop,
a security key in a drawer?
Can they see them,
name them,
remove one they lost?
What does recovery look like,
when reset your password
means nothing to someone
who never had one?
What do your support scripts
ask a caller to confirm?
Then the small things.
The login field
can offer passkeys
straight from the browser's autofill,
with webauthn in its autocomplete attribute.
Your audit log
should record which kind of sign in happened.
Your tests
should cover a user with no password,
because soon
that will be an ordinary user.
You do not have to remove passwords.
Most sites will carry both
for years.
But make the password
one way in,
not the definition of an account.
Schemas outlast the reasons
behind them.
Make sure this one
does not outlast the password.
– Serguey Asael Shinder
Top comments (0)