> A passkey is a synced, discoverable WebAuthn credential.
This is my fundamental problem with passkeys: I don't want to use any syncing service.
To be clear, I don't want to deprive other people of the ability to sync their credentials; I simply want to opt out myself. I just want to be able to manually back up and restore my credentials, like I've always done with passwords, but the passkey vendors seem to want to refuse to give anyone this ability. The vendors claim that this is to make phishing impossible, but I abhor paternalism in all forms, and also it's suspicious that this paternalism forces people to use the syncing systems of the passkey vendors, which are usually paid subscriptions. So passkeys become an endless supply of money for the vendors.
It's very telling that passkeys were designed and shipped without any export/import mechanism. You can plainly see the priority of the passkey vendors, which is to lock you in. Allegedly, export/import is coming sometime in the future, but I strongly suspect that they'll end up with some kind of "approved provider" system so that the big passkey vendors can retain absolute control and avoid giving power to the users.
This is the exact reason I self host vault warden. I get all the convenience of syncing passkeys, but know that I am the only one with access to the back-end.
I am also slightly paranoid as a security engineer, and admit that whole heartedly.
I share your paranoia and felt that passkeys were a step back as anything getting access to your browser extension memory can realistically dump both your "password" and MFA ("passkey") in one move.
I wonder if there would be a way for vaultwarden to wrap passkeys such that a hardware FIDO2 key is needed to decrypt them "per-use", and prevent software on the host from stealing a pile of passkeys that give direct access to accounts without further MFA.
Right now it feels like passkeys in the password manager is akin to storing MFA seeds and recovery keys in the same password manager...
I'm also waiting for a password manager that tightly integrates with a hardware device to protect passwords individually and in-memory.
I wrote a quick PoC using certificates to encrypt a password, with the cert private key 'stored' in the TPM, with a PIN. This is pretty easy on Windows, which exposes the TPM as a special crypto provider.
If you wanted to go a step further, you could use a smartcard with hardware PIN reader as a PKCS11 crypto device, and use that to decrypt the long lived keys in the store, then pass it back to the host encrypted by a platform-protected key to be decrypted and used.
If you could get the right implementation specifics together, you could likely then have the smart card simultaneously re-encrypt the credential with a key bound to PCR state of the TPM via a policy. You'd then decrypt that ciphertext on TPM without a PIN, but conditional on PCR state of a couple of PCRs that represent your system like the secure boot toggle state and allowed CAs.
That lets you be a bit more "cross device" than a fully TPM solution does, though your certificate technique works fine as long as you keep an offline backup for enrollment if anything changes on your system.
That's a fair point, although as the PIN is validated locally, you could argue from the server perspective you gain a second (knowledge) factor, but from a local perspective it's entirely correlated with the existing stored factor (a weakness in the local device implementation can skip that PIN check and yield the result).
Perhaps this is excessive, but it's a model where I like to see layers of security that depend on different, uncorrelated failures being required to bypass them.
Today if you want to get into an account using "FIDO2 as MFA" you need both the account credentials or ability to reach the Fido prompt (say password reset), and the hardware token device (with optional pin). The device alone being compromised shouldn't get you into the account.
For anything that is important enough, I put passkeys on 2 separate FIDO2 key devices directly. Services that come to mind are things with recovery backdoors; like email or device backups. Unfortunately many banks and financial institutions don't support passkeys, but I'd consider using that solution there too.
The downside of this (at least in my personal view) is it's a regression from the elevated security you got with non-resident FIDO/U2F MFA.
The moment you go "passkey" and have to use a system like the one you suggest, you need to trust software based storage of long term credentials.
That isn't the case with a hardware FIDO2/U2F token, which has unlimited capacity for non-resident MFA keys the server holds for you to decrypt and use locally to sign login attempts.
I liked that FIDO seemed to get towards hardware backed security modules for login, without cognitive load of worrying about number of sites and yubikey slot capacity. Resident Webauthn keys limit the number of sites you can have, and push you towards software based solutions (so you lose out on doing the crypto on the single purpose, limited platform that's dedicated to generating those signatures).
I agree that it's annoying that there's now a limit on the amount of credentials you can store on hardware keys. But while older Yubikeys only support 25 resident keys, models with firmware 5.7 onwards support 100. That probably makes it feasible to exclusively store passkeys in hardware.
https://www.yubico.com/blog/empowering-enterprise-security-a...
However, I don't know whether it's possible to delete only a single resident key you no longer need.
Yeah, a fair point (though if you can't manage keys one by one that seems a massive usability issue and oversight with no safe path to resolution).
This adds another step needing considered for a user, as finite storage means a whole edge case to consider (can't register as slots full), and no simple actionable step to take ("which account would you like to never be able to log into again?" or "sorry you need to wipe this key and lose everything, or buy another one")
I feel there is a usability aspect of FIDO2 (for non-resident MFA) that is being overlooked - the paradigm was simple - a physical key you don't lose, and you can have multiple keys. The gotcha was no way to replicate backup keys, which becomes fairly difficult for users. But hey - passkeys launched with no export or migration process between closed device ecosystems!
From my perspective though, I won't use passkeys until I get sufficient control over them to be allowed to decide if I want to make them "resident" or not. (I don't want resident keys!!)
I want to use non-resident keys everywhere as a hardware-backed second factor that is phishing resistant, without capacity limitations (so zero cognitive burden on whether to use or not).
It feels like a regression for passkeys to be forgetting about what (for me at least) was the core basic use-case of FIDO2 - as a highly secure second factor for someone who already can manage storage of secrets in software, and just wants high assurance phishing resistant MFA during their conventional login process.
I'm honestly very annoyed with Yubico that they just froze their product line-up circa 2018 and pretend the major changes in firmware (5.2, 5.7) don't matter at all and don't warrant a separate SKU.
I haven't really looked into it myself, but it seems to be using the same database format as KeePass, and it hooks into macOS's "FIDO provider" API, which makes it accessible to not only Safari but all browsers that use it (which includes Firefox and Chrome on macOS, and probably everything on iOS), without requiring any browser-side extension.
At some point, you have to trust something. Thats how I feel about WebAuthN and syncing services.
Ideally, some of this could actually be solved by having a government organization that provides this and is regularly updated / audited etc. but in the US at least, we are not in any place for that to happen, so you need to pick a provider.
Apple is reasonably good at this, if you're in their ecosystem. Can't speak for Google. 1Password has been very good to me as well, and there are Yubikeys too.
Nothing is perfect, but this is a far, far far better state than were it was heading before WebAuthN
Some service. I’m not saying you have to trust what I trust.
Personally I’m a big 1Password fan and have been in the Apple ecosystem for a very long time as well.
Most security folks I trust also vouch for them, as far as practices and effectiveness goes of their software.
But you’ll need to trust something somewhere, and you might even need to expose it to a network in some cases.
The one thing I really like about Yubikey is it doesn’t require a network connection at all to work, but it never caught on generally for that model to be widespread supported so I have found while I do use my Yubikey a fair amount there are still things that don’t accept it that I wish did
> But you’ll need to trust something somewhere, and you might even need to expose it to a network in some cases.
Again, no, I don't, and you still haven't explained why. Unless you mean that the big tech companies will force me to use a sync service whether I want it or not.
Moreover, you've ignored my point about paid subscriptions.
Again, may need to. It’s not a guaranteed, perhaps your situation doesn’t require this. That’s cool, but not everyone’s is yours and yours not everyone’s.
When it comes to paid subscriptions I have no issue paying for something I get a lot of value out of, but there are free alternatives that are good today as well, like Bitwarden and I know others have mentioned 100% local installations that work too. Not to mention, if you are in the Apple ecosystem, Passwords is free, it doesn’t cost anything and can take advantage of all this.
As a matter of practicality for me though I find it overall easier to use 1Password for example, but that’s just me and if someone asked I’d recommend Passwords by Apple or 1Password but again, doesn’t need to be those things
Not to mention that a better security would involve a master key, and revocable subkeys signed with it, one for each device, instead of syncing. Not to mention n-of-m requirements.
And sure, I understand that most people need the paternalistic form, whey they are not given any guns and are also unable to export their keys from some service.
For example, with TOTP, the key is given to the user in the QR code, but common authenticator apps are unable to export the same data after it was imported. But not all; and the only bad thing about this is that the export restriction is a surprise to those who didn't expect it.
I was messing with implementing webauthn the other day, mainly because I like public key authentication. I was hoping for something sort of like ssh keys. and they were close, so close, to having something good that could replace password auth. and then they break it by requiring a hardware token, Yes, a hardware token is better, but I am not going to require users get a hardware token. there are working software token systems built into the browser but they are gated behind dev tools, again something I am not going to ask of users. and just to spit in whatever goodwill they have left, to make it really unusable, there is this weird mandated "no user interface" policy in the standard. making near impossible to manage keys. The keys are critical in a public key auth system. but "no, we are disallowed, by the standard, to give you an easy mechanism to back up and restore keys"
If I were more conspiracy minded, I would suspect some sort of agent provocateur ruining our standards. However, I am unable to come up with a profit motive, so my only conclusion is incompetence.
You used to be able to generate X.509 client authentication certificates (well technically CSR) right in the browser with the since removed <keygen> tag. Ergonomics weren’t that bad, until a user forgot they had a certificate on their broken PC.
As somebody that used to use them for a while: The ergonomics of TLS client authentication in the browser were abysmal. And that's to say nothing about the privacy consequences.
iirc managing them was buried super-deep in the browser settings (just like managing resident keys, browsers don’t even do that), but enrollment was fairly simple from a user PoV - submit a form and the server sent back the certificate, iirc you had to confirm a scarily worded dialog (or maybe import it manually? Not sure). Login was smooth if I remember it - just a pop-up if you want to use the installed certificate. Privacy should be fine with TLS 1.3 but would’ve been nonexistent with the contemporary SSL/TLS versions of course.
That's unfortunately not how it works. TLS sits at the transport layer, so it's not possible for a website to use these certificates for a "login-like flow". The site doesn't get to present to the user why and to whom they are authenticating, since transport layer authentication has to happen before HTTP even gets a single request in.
There is also no "logout" button. It shares these UX problem with HTTP "basic authentication" (even though that's technically an application layer protocol).
On top of that, TLS is these days often terminated by a load balance or even a completely separate entity like Cloudflare. Not sure if you can configure these to request client certificates at all; even if you can, it makes things pretty awkward if you want to have closer control of the authentication flow.
> Privacy should be fine with TLS 1.3
It's not fine at all. Any HTTP server can request your client certificate, and most users would probably not think twice before clicking "authenticate", which then reveals their long-time stable certificate and public key to a potentially malicious server.
Compare that with WebAuthN, which makes it intentionally impossible to accidentally present the certificate for a.com at b.com.
The implementation ends up being a new key gets generated per domain, which is actually what you should be doing with your ssh-keys as well something like "ssh -i server.domain.net server.domain.net"
Because webauthn is such a nonstarter I am actually going to try and half-ass it using SubtleCrypto.sign() and friends. sort of mimic the webauthn api. This is really just a weekend project, nothing important. but I feel really stupid every time I work on it, mainly because of how ridiculous it is to have your key infrastructure managed by the service you are logging into.
However due to domain sandboxing I have half convinced myself it is as secure as using a cookie to auth the person, perhaps even a little better because I never have to see a secret. then fall into despair again on how stupid this whole endeavor is, because I could see the keys anytime I want to. (sighs, shakes fist at the sky) why could you have not made webauthn usable?
What specific gripes do you have with WebAuthN that makes you want to reimplement it?
All the problems I have with it as a user originate from either reyling parties doing dumb/user-hostile things (enforcing resident keys even though I'm perfectly capable of remembering my email address or my username, improperly layering WebAuthN with existing second factors etc).
These are possible because WebAuthN is trying to provide for many use cases at once, but I've never felt like it was missing something, and user-friendly behavior is definitely possible. I've seen many examples at this point.
No good way to manage(save/restore) the keys. but the real killer for me was that it requires a hardware token to work, while a hardware token is better, it sort of sucks as a hard requirement for all users.
Really, I don't want to reimplement webauthn, I will will probably be sticking with basic auth as it just works. However, I was hoping to finally get decent public key auth. and webauthn is close, really close, but it is like the designers gave up at the last second and said "no, we don't want this to work in the general case", all it would have took was to say software token are an ok fallback. I was so close that out of frustration I spent a weekend with an experiment to make public key auth work for everybody. It works, but is a bit pointless as then I, the service needing to authorize somebody, is the same person providing them their public key management system. I might as well cut out the all the ridiculous bit twiddling and just use cookies for all the security that grants the end user.
This is my fundamental problem with passkeys: I don't want to use any syncing service.
To be clear, I don't want to deprive other people of the ability to sync their credentials; I simply want to opt out myself. I just want to be able to manually back up and restore my credentials, like I've always done with passwords, but the passkey vendors seem to want to refuse to give anyone this ability. The vendors claim that this is to make phishing impossible, but I abhor paternalism in all forms, and also it's suspicious that this paternalism forces people to use the syncing systems of the passkey vendors, which are usually paid subscriptions. So passkeys become an endless supply of money for the vendors.
It's very telling that passkeys were designed and shipped without any export/import mechanism. You can plainly see the priority of the passkey vendors, which is to lock you in. Allegedly, export/import is coming sometime in the future, but I strongly suspect that they'll end up with some kind of "approved provider" system so that the big passkey vendors can retain absolute control and avoid giving power to the users.