Is there a good ELI5 for passkeys somewhere? A quick google got me to a site that says:
>Passkeys use Bluetooth technology, which requires physical proximity, to help verify the user.
Which I somehow doubt is accurate.
>Passkeys use Bluetooth technology, which requires physical proximity, to help verify the user.
Which I somehow doubt is accurate.
A passkey is an implementation of public key authentication.
The private part should stay with you, this is your identity. The public part gets shared with others, they can use this to verify your identity. "microsoft passkey" wraps all this up into a simple tool that just looks like you are putting in a pin number.
The vague thousand foot mechanism is. someone who wants to verify your identity will ask you to sign a unique number. because only you have the private part needed to to do this, only you can sign it correctly. they can then use the public part to verify the signature is correct. and know it is really you they are talking to.
The private part is usually protected by a device, something to prevent others from using it. this is often just a password, in this case a PIN. but some times is a dedicated usb dongle. this only has to have local security guarantees not global network security guarantees. so a simple password like a PIN is not considered a problem.
The primary advantage over a simple password based system is that the thing that is shared(the public part) is unable to be used as your identity so it can't be stolen like a password. or perhaps more accurately, it does not matter if the public part is stolen(it is already public knowledge)
And now the irony, I have no proof, however I have a suspicion that because loosing the private part is the same as loosing your identity, that is, a big deal and a huge hassle to recover the account. I suspect microsoft is storing them internally. which means your account security degrades to a password based system where the password is basically pubic knowledge, that is, your so called security questions. what is your favorite color? is not a good password.
1. Passkeys contain the username and the domain of the service that you have registered with
2. Because passkeys contain the domain, it provides very strong phishing protections, because a look-alike website still has a different domain.
Passkeys are resident keys. They take up storage space, which is a problem for dedicated hardware tokens which usually have limited storage space. A much nicer solution are non-residential keys that get recomputed on the fly based on the domain name that you want to authenticate against.
The site registers itself with your passkey "wallet" (?), and logging in would use a signed request and your wallet provides a shared secured response so you both can confirm who you say you are?
No. This is orthogonal and can be used in combination with the aforementioned technologies.
Let's assume you want to use OpenID connect and also JWT.
1. You have your own web service that does not implement a login form but relies on OpenID connect.
2. You have an authentication service like GitHub, Facebook, Google, ...
3. Your users have a pre-existing account on GitHub, Facebook, Google, ... They use their passkey/non-resident key/plain old password/... to log into one of these services
4. Your users want to log in to your service. They start the OpenID Connection protocol using the authentication service. If they are not logged in yet, then they have to present their passkey/non-resident key/plain old password/... to get logged in. Once they are logged in, the authentication service can issue a fresh JWT to your user.
5. Your user can then use the JWT to use your service.
Sounds like basically public key logic with a biometric local wrapper?
Thou shalt not sign arbitrary plaintext
… if, as you say, a service first gives you something to sign with your private key ?
What kind of “phishing” would it be if Mallory convinced Alice to create a new account on some new service for the purpose of leaking private key bits?
Really I am not an expert in this field, but
As far as I can tell signing arbitrary plaintext is a core mechanism in how public key auth works.
The theory is you have to sign something to prove your identity. this thing you sign has to be provided by the authenticating body and should only ever be used once to prevent replay attacks. that is you never want a situation where someone can give you a copy of the signed message and login.
For example, and the only one I have actually read the standard, during auth ssh signs a number of fields, the critical one being the session id. the session id is provided by the server and is only used once, thus satisfying this critical part of public key auth.