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.
$ oathtool --totp -b "S3GXITTAZXNN4LCPXWQREDYBIE"
646063
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.
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.
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.
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.
so, yeah, thanks, no thanks.
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.
Can you share any details about the sites?
I hate this so, so much.
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.
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.
Typically, when you turn on 2FA on a service they give you a handful of one-time codes exactly for situations like that.
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.
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.
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.
Really? I always thought it was a single key. How does that work without having devices run out of storage?
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)
Each passkey is a modest amount of data, and I don't see a person having so many passkeys that the TPM gets full.