I do not want anything to do with this, but I imagine I'm about to be railroaded into it anyway.
It's bad enough that so many web sites are starting to assume I must have my phone handy and I must have cell service where I'm sitting. I didn't want to give them my phone number in the first place but now they're SMSing me before letting me in, and if I happen to be out in the boonies, unable to receive their six-digit code... they don't have a solution for that.
physical keys, the equivalent of passwords, have been working for millenia and will keep working in the future, despite their limits, which present a good trade off generally speaking.
everything biometric is scary as hell, I can't change my fingerprints.
everything involving cryptographic keys has the same problem: if someone get ahold of my keys, I'm f*cked.
if I need a device to be close to me, the solution is not as bullet proof as they make it sound.
we all know nobody ever loses their devices or forgets them on the train, they never get stolen, they never break or suddenly stop working.
They also admit that
Passkeys aren’t reused across sites like passwords often are, so stolen credentials do less damage
or
It sounds simple enough, but in my experience, I’ve found that the process can be confusing. When I attempted to test it by creating a Kayak account, I repeatedly got stuck waiting for a verification email that never showed up. Eventually, I managed to log in, and the passkey worked seamlessly on an iPhone. But when I tried to create a passkey on my Mac, I was locked in a loop where the site repeatedly asked me to enter my email address; I soon realized that I had to select the option to scan a QR code with my phone because my Mac mini doesn’t have Face ID or Touch ID, and I needed to authenticate on a device that does. At no point in the login process was that made clear.
When a password manager has both the password and the secret for TOTP, that always seemed like it degraded the concept of multi-factor authentication to me.
Personally, I don't, I explicitly and intentionally keep my Email, Password Manager and 2FA providers all distinct and separate. (This was very useful for extracting the TOTP secret out of the Symantec VIP 2FA system: https://github.com/dlenski/python-vipaccess)
At work, we do for non-person accounts. It's non-ideal, but I don't want to manage two separate systems for storing that data and trying to keep them in sync. The password vault system itself has a hard requirement for 2FA to download the vault.
Convenience and security are constantly at war with each other.
I've decided that, for me, the risk of someone obtaining access to my password manager is very low. I've been using password managers since ~2000, randomly generated passwords; I've never had an account compromised.
There's enough other sensitive information in my password manager that if someone did obtain access to it, I'd be fucked anyway, to the point that someone getting my TOTP secrets would be minor.
I made a simple TOTP client in python so the device they assume I have is the same device from which I intent to log in. Sadly I can't do that for services.
recently I found myself in an interesting conundrum; I was for a time near a timezone boundary and so I had my phone's "sync clock to network clock" disabled.
At a certain point I discovered that some of my OTP apps stopped working which I blame on my phone's clock drifting by almost 2 minutes.
Hmmm. I haven't seen any hard numbers on this, but I can only think of a few sites that made me turn on MFA, and they were financial in nature. Many many sites encourage MFA, but I haven't run across too many that require it.
It's becoming increasingly common for sites to not offer password authentication at all. Instead they send you a SMS text or email with an auto-login link.
I dislike that intensely as well. I don't have any trouble with sites offering magic link login, but to have that be the only option seems short sighted to me.
I worked at a company once that only offered federated login. It was a dev tool, so they offered login with google or github. I disliked it, because, hey, maybe I don't want to link random devtool with the core accounts I use.
I'm not aware of any research that shows what the conversion rate is for each type of login:
* username/password
* magic link
* federation (login with google, etc)
But I'd sure love to see it.
I imagine it would also vary by application type (devtools would be skewed towards username/password, consumer towards federated login or magic link) as well.
It’s slows your login significantly, it’s cumbersome. The more often you have to do it, the more infuriating it becomes. Disclaimer: I hate this as well.
Because SMS may not arrive. E-Mails may be delayed or blocked by spam filters. You may not have e-mail set up on the device you're trying to log in from - so what will you do with a link on another device?
Meanwhile, a password is something you already have at hand and works instantly.
Recently tried 3 weeks to setup Slack because it's magic mail did not arrive. Was even unable to reset the password. We just gave up and used another e-mail service provider and created a ned account.
Fair enough. There is a solution to your problem, but if websites don’t implement it then it’s the same as no solution. Do double-check if the services you most depend on have added the feature since, though, as you may able to get the codes now.
Passkeys are just using WebAuthn as the primary authentication method. WebAuthn works by users having a separate private key for each site, with the sites storing a copy of the public key, and sign-in works conceptually by the site generating a nonce, which must be signed by the private key, with the signature presented back to the site who can verify it against the public key.
The problem though is that WebAuthn is most convenient when using the platform authenticator (so you don't need to plug in a U2F style dongle). But conceptually the platform authenticator is tied to a single device. (Because the private keys are supposed to be stored within a TPM or secure element of some form). But that means if you lose/damage the device you are locked out.
Obviously one option is to have a lockout flow that asks security questions, or sends an email or something, but obviously those are not nearly as secure as private key stored on a device you need to physically possess. Plus generally you need to authenticate to the device too, with biometrics, or pin, or something, before WebAuthn flow can proceed, making these flows inherently two factor (something you have, plus either who you are for biometrics, or something you know for pins).
The original solution for this was to always register a roaming key (like the U2F style dongle), as a backup, and as a method to initially sign in on a new device (aftwe which you could enroll the platform authenticator).
But nobody does that, so instead most platforms are also storing a copy of these passkeys in their associated clouds, meaning that if you lose your device, you can get a new one of the same type, sign in it the Microsoft/Google/Apple account, and you can now sign into sites that use WebAuthn as sole authentication again.
But this only helps when moving between devices in the same ecosystem, what if you only have an account on your iPhone, and want to sign in on a Windows PC? The new idea is to allow this via scanning a QR code, and verifying that the two devices are physically near each other (verified via bluetooth low energy). (So this will work for laptops, but not all desktops have bluetooth). Obviously once you sign in like this once, you could then add the new devices platform authenticator as a sign in method, so you don't need to do this every time.
This cross-device QR sign-in approach is being standardized via FIDO, although as far as I can tell there is no published specification right now. Draft versions of FIDO specifications are not publicly available, with the exception of the WebAuthn spec, since that is developed jointly with W3C, under the W3C process. But most of this would be on the CTAP side of FIDO2, which is a pure FIDO developed specification, so the only way to see the current draft specification would be to become a FIDO member.
Yes, we built out WebAuthn (more here: https://fusionauth.io/docs/v1/tech/passwordless/webauthn-pas... ) and explicitly have it enabled for the re-authentication workflow right now. So WebAuthn is a nice way to reduce friction for existing users, rather than a way to create a new account.
The account recovery issue is a big one when you don't have any other credentials than WebAuthn credentials, as you touch on. I believe the next version of WebAuthn is working on standardizing this, which might help with the ecosystem issues you raise: https://www.w3.org/TR/webauthn-3/#sctn-usecase-new-device-re...
> a low-friction means to strongly re-authenticate on client devices having platform authenticators.
IE: People in big tech think everyone on the planet should have at least 2 modern devices and sign in to their big tech cloud accounts on all of their devices.
I'd also be willing to bet there's no thought given to de-authorizing a key, so when my parents/siblings/niblings recycle their 5+ year old devices without wiping them first they better hope there aren't any known security flaws for those devices.
On registration, the server is handed a site/user-specific key pair _encrypted_ with the master key of the authenticator device (your usb key or your phone, etc), together with the plain-text site/user-specific public key.
On authentication, the server sends down that encrypted blurb, which is temporarily decrypted and then used to sign a challenge the server sent.
So basically the server is used as storage. There are exceptions to this (e.g. resident/discoverable credentials on hardware keys)
No -- every origin has it's own Public/Private key that is stored on the TPM chip on your device. The TPM is designed specifically for securing these keys.
Each passkey is a modest amount of data, and I don't see a person having so many passkeys that the TPM gets full.
Why do you need qr codes if a user account can be associated with multiple webauthn credentials on the server side? Surely a user can log in with any device then?
How do you securely register a second phone/computer? You should ideally be signed into the site on that second phone/computer to register it, which is what the QR code helps with. Once signed in, you can then securely register a key from the platform authenticator of the second computer.
After all the idea of passwordless authentication is to not even have any password as a fallback. If you do have a password based fallback, then obviously you can use it to sign in to register the new device, but since WebAuthn is far more secure than a password, the preference is to not have such a fallback. And of course, an account recovery flow based on emails or SMS and possibly "security questions" are almost worse than a password.
The QR code is far more convenient than needing to buy a fido2 security dongle, especially one that supports USB-A (for most desktops/laptops), USB-C (for android/iPad/other laptops), and lightning (for iPhone), so you can register it via any already registered device, and then use it on any other device for initial sign-in.
You apply with the untrusted one, sign in with the trusted device then approve the untrusted one. Same way as you add another fingerprint to a device for example by providing an already trusted identity.
While I'm totally in support of public/private keys, FIDO and the like, can we just not move to a different 1 factor? Security is always about layers. The whole point of a (good) 2FA is to be a secondary factor. How long before there is a zero day discovered that lets someone MITM a passkey on your mobile device?
Passkeys as implemented are normally multi-factor. You need to both posses a device whose platform authenticator contains a key registered with the site, and also enter either a PIN, or use biometrics. On mobile devices this is done via the same options available on the lock screen, while for Windows this is "Windows Hello". I'm not sure how MacOS works here, but presumably similar to iOS.
As an alternative to using a platform authenticator a FIDO2 security token can be used over USB, bluetooth, or smart card NFC.
It is up to the site to specify if user verification (i.e. a second factor) is required, or not. If required, the authenticator must verify the user, typically via biometrics or PIN, although a desktop OS may fall back to login password. The website may instead specify "preferred", which generally requires a second factor, but allows an authenticator to skip in in some circumstances (like if a classic password is the only verification option available, as opposed to a PIN or biometrics, since in that scenario requiring the user to type their computer login password every time is generally not a good user experience, and would be best reserved for extra sensitive scenarios).
I can't tell you how many times I've had to explain public/private key concepts to software developers with many years of experience. Usually after something is misapplied.
Yep. It's a scheme to make sure the only guaranteed way to avoid being locked out of your accounts is to sign up, and pay monthly, for a Microsoft/Google/Apple service. That's why all the recovery options are completely glossed over. It's because their solution is "pay us".
It's bad enough that so many web sites are starting to assume I must have my phone handy and I must have cell service where I'm sitting. I didn't want to give them my phone number in the first place but now they're SMSing me before letting me in, and if I happen to be out in the boonies, unable to receive their six-digit code... they don't have a solution for that.