PassKeys seem like a bad idea. Google backs them up to the cloud, so if your Google account is compromised then all your private keys are compromised. I don't see how that's an improvement over password+2FA at all.
Now security keys I get; keep the private key on an airgapped device. That's good. Hell I even keep my 2FA-OTP salts on a YubiKey.
Structural security trumps computational security ... or ...
Diffuse structural security trumps amalgamated computational security ...
All your big, strong passkeys in one basket is less secure than your passwords in many individual baskets ...
Trying to explain this to tech bros can resemble pushing a wagon uphill ...
Because they want to sell something, logic is not paramount.
"A password in my brain is generally safer than an app or SMS stream that can be compromised. Although a passphrase may in some cases not be computationally more secure than a token mechanism or two-factor sytem, the simple passphrase is often structurally more secure because that passphrase only links to and exposes one service target."
"I like to compare it to having one basket of eggs in one spot, and many baskets of eggs in many places. If your one basket of eggs has the master key to all the other stronger keys, is it easier to get the one basket, or the many baskets with weaker keys? So in this scenario cipher strength is not the most important factor for security. With a single basket one fox or pick-pocket or one search warrant can own all of your eggs for all your services."
When implementing #WebAuthn on an Identity Provider's side. Where exactly should one draw the line between #SecurityKey and #Passkey? I see that most platforms make a distinction between those. Can anyone link me some article or blog post on this topic? If I were to implement security key and passkey support on a provider that does not yet support any WebAuthn, should I go down the same route?
My current assumption is that during passkey registration you'd set "residentKey = required" and "userVerification = required", whereas for a security key you'd set "residentKey = discouraged" and "userVerification = preferred".
Also, I'm assuming that a security key can also function as a form of #passwordless multi-factor authentication if UV was true during registration AND authentication. Obviously without the neat part of Passkeys where you don't have to manually enter the username.
@hertg Something to be aware of is that there's no longer "security key registration" in WebAuthn since "cross-platform" was overloaded to include mobile device registration via QR code (a.k.a. hybrid auth.) The biggest issue here is that setting "residentKey: discouraged" when you specify "attachment: 'cross-platform'" will prevent Android devices from creating synced passkeys. You have to either "preferred" or "required" resident key creation, both of which will lead to resident keys being created on security keys too.
As an RP you can't know whether or not a user will register an Android device. Thus you can no longer discourage resident key creation for sake of security key storage (assuming your goal is to get your users to register synced passkeys.)
The new "hints" option in L3 will help with this somewhat as browsers start to support them - it'll help peel apart "cross-platform" registration into "security key" and "mobile device" registration at which point it'll be easier to respect security key storage limits. Nothing supports these right now though.
hm. Do I spend $30 (after shipping) on another #2FA#U2F security key, but this one can store 50 #TOTP (as well as work as a standard #FIDO2#SecurityKey) entries.
Compared to #yubico#yubikey which is $50 (before shipping) and stores only 32 TOTP.
It'd only be around $22, but it apparently ships from Switzerland?
@ezlin right!? My silly little toots have better security than my BANK which only supports SMS 2FA so anyone who can socially engineer a TMobile agent can sim swap all my money away 😒
When I first discovered WebAuthn in 2019 I imagined it being used for something like this, but never imagined something like the prf extension enabling true E2EE like this. Everything happens in the browser; there's no server used in any of this because to me that defeated the purpose. I also challenged myself to make a decent UX on top of this because what good is strong encryption if it's not usable?
For best results make sure you're using Chrome 116 and a recent FIDO2 security key.
(I'm also trying to figure out how things get noticed on Hacker News, so if you participate over there here's the Show HN, upvotes appreciated: https://news.ycombinator.com/item?id=37148972)
tldr;
Question: is there a way to use your Simple WebAuthn server to only show registration options (ie. PublicKeyCredentialCreationOptionsJSON) for specific AAGUIDs?
I've built out a full E2EE auth system (web app with Node backend) using the PRF output for each authenticator to derive a local ECDH private key wrapping key, unwrapping the private key with this key, deriving the master key wrapping key with the local ECDH private key and master ECDH public key, and then unwrapping the master key with this (I'll probably throw some other steps to allow the master key to not be extractable on the client side, it's currently bisected in memory and session storage see here if you're interested: https://github.com/47ng/session-keystore). Anway as we know PRF won't work with the iCloud Keychain until Apple fully supports it :(
<insert tldr;>
I want to send an array of authenticators that will work with my system eg. Yubikey 5C NFC, Andoid Google Password Manager (as long as the browser supports PRF natively). I know I can get the AAGUID in the second step (VerifiedRegistrationResponse.registrationInfo) or just kill it on the browser when PRF supported is false but I want to not even show the options that won't work.
Currently I'm sending UV = required, authenticatorAttachment = "cross-platform", RK = required. Then I show a popup when a MacOS user tries to enrol their iCloud Keychain (maybe I'll add a master password/SRP protocol in so I can put this on the Apple store too then ditch it when Apple hopefully adds supports for the PRF extension).
Also I'll send some commits your way soonish to fix the types for the PRF extension - it's a bit hacky how I implemented it.
@ragnarbull Unfortunately WebAuthn has no way for an RP to require specific properties about an authenticator before a response is generated. You have to receive a response, check for the desired properties, and then accept or reject accordingly.
WebAuthn is more user-driven than RP-driven in the sense that users can bring any authenticator they desire to an RP, for the RP to then choose to recognize it or not.