It’s different. It’s still two factors if implemented correctly: 1. Possession of the passkey (better if you have a physical token, but passkey on your phone is passable). 2. Knowledge of your password (or bio authentication if you use face id or w/e).
Note you are not giving your password to the website, and if a hacker gets hold of your password they still can’t do anything without your passkey device.
It’s client specific and my phone requires whatever can unlock the phone and chrome requires either windows hello or a pin if under linux.
Certain implementations do whatever, and as far as the backend is concerned, there’s no way of knowing, unless you want to get into the business of locking down specific vendor keys…
But I say MFA is overrated versus just getting away from generally crappy password factors. Also passkeys are less phish-able than OTP type solutions.
Yes, it’s implementation specific, in this case your phone, or your browser is the passkey “device”. And as long as it’s protected by some form of authentication it’s OK (though I would recommend a hardware token over phones/browsers). If it doesn’t then you shouldn’t be using that “passkey”. Yes, there is no way for the website you are authenticating with to know whether your passkey is safe or not, choosing a secure passkey implementation is (unfortunately) the user’s job. But it’s the same with more traditional 2FAs, e.g. you can store your TOTP secret securely or insecurely, and the website will have no way to know.
It’s different. It’s still two factors if implemented correctly: 1. Possession of the passkey (better if you have a physical token, but passkey on your phone is passable). 2. Knowledge of your password (or bio authentication if you use face id or w/e).
Note you are not giving your password to the website, and if a hacker gets hold of your password they still can’t do anything without your passkey device.
Uh… What password?
Passkey should ask for a password for unlocking. If it doesn’t then it’s not implemented correctly.
It’s client specific and my phone requires whatever can unlock the phone and chrome requires either windows hello or a pin if under linux.
Certain implementations do whatever, and as far as the backend is concerned, there’s no way of knowing, unless you want to get into the business of locking down specific vendor keys…
But I say MFA is overrated versus just getting away from generally crappy password factors. Also passkeys are less phish-able than OTP type solutions.
Yes, it’s implementation specific, in this case your phone, or your browser is the passkey “device”. And as long as it’s protected by some form of authentication it’s OK (though I would recommend a hardware token over phones/browsers). If it doesn’t then you shouldn’t be using that “passkey”. Yes, there is no way for the website you are authenticating with to know whether your passkey is safe or not, choosing a secure passkey implementation is (unfortunately) the user’s job. But it’s the same with more traditional 2FAs, e.g. you can store your TOTP secret securely or insecurely, and the website will have no way to know.