251–260 of 600 posts
Earlier quoted context omitted.
Your 2FA app of choice doesn’t support export/import?
I was forced to create my first ever Microsoft account to be able to back up my Microsoft Authenticator app. I struck a small blow in return by using a very rude email address for it.
Earlier quoted context omitted.
> Passkeys are unphishable and can't meaningfully leak credentials in the case of a hack, nor can they be reused by design. Let's assume a "passkey device emulator" written in software; quite realistic IMHO for someone to use, considering the cost of hardware authentication devices (phones, YubiKey etc.) If someone using such emulator gets hacked and has their passkey emulator data stolen, is there anything preventin…
If the device is exploited, they can also install a keylogger and steal regular passwords. I think this would be where hardware based authentication via TPM or similar would be useful. This would allow the device to be taken over and the private key material would still be safe.
The secrets in the password vault can be used to authenticate and change settings in various trusted systems, like configuring call forwarding.
Cloud-based backups or the local filesystem could theoretically be inspected for software TOTP secrets.
Responding to the potential for bad user choices and full compromise quickly gets you to the point where your options are separate hardware or requiring in-person confirmation. NIST 800-63-3 AAL3 is probably most appropriate to look at if your risk profile mandates this.
Or until it works like this: https://youtu.be/rERApU26PcA
And then logging in will look exactly like this: https://youtu.be/AJ6gdRfBW6c
Earlier quoted context omitted.
> Passkeys are meant to be a password _replacement_, No. Passkeys parasitize on FIDO2 U2F standard, that was developed to be (as the name implies) the second factor. Resident keys are meant for on-device 2FA with PIN, a functional replacement of smart cards. Someone (Apple maybe) thought it’s a good idea to consider WebAuthn being good enough to be the only authentication factor (no resident keys, no hardware bond, k…
Microsoft Live allows me to sign in to live.com with nothing else but my Yubico Security Key. That's right, I don't even need to know my username; I just plug in the key and touch it and I'm logged in. And when I write "I" you should read "anyone who has physical possession of this key". I think that's astonishingly bad opsec for a Big Tech cloud service. If I were a sane person, I would deregister that key as a FIDO…
You don’t have to do it this way. I configured my Yubikeys to be the second factor and not to use resident keys. It’s possible, although I don’t know if Microsoft allows users to roll back from “passwordless” and discoverable keys.
I want to state it explicitly: FIDO as technology allows either. It’s particular platform choice to go with discoverable keys.
Earlier quoted context omitted.
> Passkeys are an insanely overcomplicated solution we don't really need. This is simply not true. WebAuthN is not overcomplicated needlessly (I wouldn't even call it over complicated, it's literally just a signed challenge/response dance). It improves on Passwords+2FA in a few notable ways: 1. It prevents shared secrets from traversing the wire. 2. It naturally enforces that users are all using secure authentication…
I'm desperately looking forward to my password manager integrating support for Passkeys such that I can: 1. Back up my keys to paper and restore them from paper 2. Disregard/end-run around the "user presence verification" challenge if I want to. I already deal with a ton of "acknowledge this push notification" or "type in this TOTP code" to verify, and automating every one of those interactions has lifted a huge amou…
Since Apple didn't actually define it, this left a void for our thought leaders to answer that question for users hungry to know "what indeed is a passkey?". I have always understood that Apple defined a Passkey to be a key pair that is synced through iCloud Keychain. Even their WWDC 2021 presentation distinguishes passkeys to be different than security keys because they are "always with you" (the device sync aspect)…
Their goal was an industry initiative, not an Apple Passkey product. By the time they were released in 2022, the definition loosened to be an experience, e.g. discoverable and providing the option for user verification.
The user can choose whether or not to use a passkey provider that is backed up/recoverable, and the relying party gets a signal to this effect. They might use this signal to determine whether to prompt to remove the password login option.
Earlier quoted context omitted.
Microsoft Live allows me to sign in to live.com with nothing else but my Yubico Security Key. That's right, I don't even need to know my username; I just plug in the key and touch it and I'm logged in. And when I write "I" you should read "anyone who has physical possession of this key". I think that's astonishingly bad opsec for a Big Tech cloud service. If I were a sane person, I would deregister that key as a FIDO…
Yes, that’s resident (or “discoverable”) keys the article author is talking about. You don’t have to do it this way. I configured my Yubikeys to be the second factor and not to use resident keys. It’s possible, although I don’t know if Microsoft allows users to roll back from “passwordless” and discoverable keys. I want to state it explicitly: FIDO as technology allows either. It’s particular platform choice to go wi…
No, I said I'm using a Yubico Security Key. This is not a Yubikey. This key has no storage. How can it possibly store resident keys? The YubiKey Manager app can't even connect to this key. It's very basic, it has no TOTP slots, it has no configuration, it only does FIDO2. How would resident keys get in there in the first place? The article cites a strict limit on the number of slots, but it has zero slots.
Earlier quoted context omitted.
Until there is something like pre-registration ("here are all my keys from all my devices, trust them all" - not possible with current standards) mechanism - I suppose, yes? I don't really understand if there's any other way to make all this work if not for portable authenticators. How one is supposed to log in from a different machine if it's from a different ecosystem that doesn't have the original passkey (e.g. lo…
For the other direction (phone providing computer access), there is a hybrid flow. You select an option like 'use passkey from another device', and it will pop up a QR code. Scan that with your phone/tablet, and it will provide the interface to confirm and authenticate on your phone. That then lets your computer in. Some sites may have flows to detect you used a credential from another device when your local device s…
Is this a part of any standard? It most certainly not a part of any Webauthn spec, and sites I've seen that mentioned Passkeys did not offer this option.
I see a lot of comments mentioning "residual keys". Is that the same as the "resident keys" the article talks about?
They're just using the wrong word.
Earlier quoted context omitted.
It means though that your secure hardware token has a reliable way where the secrets all self-destruct. That someone can easily do if they get even brief hardware access. For people who have a problem keeping sufficient backups (almost everyone on earth) this seems like a horrific blocker, a show stopper for this entire intiative. I personally think these things absolutely should be able to be exported & backed up se…
> I personally think these things absolutely should be able to be exported & backed up separately. I agree. The usual response is that you don't need to do this because you can have multiple hardware keys that authenticate to the same services, so you can store one as a backup. But managing that sounds like a real pain in the butt to me (honestly, the entire passkey system sounds like a real pain in the butt to me --…
Just some problem: As a backup, I would prefer to store it _away_ from my main hardware key. Everytime I sign up a new service, I need to go fetch the backup and update it...