Hard, hard disagree. They’re really not. Password reuse is rubbish. Passwords human beings can remember are rubbish. But a secure password — i.e., a random value with 128 bits of entropy (such as a random 28-letter string) known only to the two parties to an authentication — is not rubbish.
There is the very minimum amount of protocol necessary: one party asks for it; the other party provides it.
The end user can pick his own software to manage his passwords, or none at all (a piece of paper in a wallet is remarkably secure) and the relying party to has no ability to approve or disapprove.
I do agree that WebAuthn offers very real improvements over passwords (principally due to no longer being a shared secret), but it makes things worse for the users in a few ways. For one, the ability of relying parties to blacklist or whitelist authenticators tramples on the user’s freedom to use the software he wants. Attestation keys and enterprise attestation are user-hostile: users and servers are no longer equal parties.
And finally, the user experience of passkeys with, say, a phone-based authenticator is miserable: one must interrupt one’s computer usage, pick up the phone, unlock the phone, open the notification and unlock the app, then put the phone down.
All in all, while WebAuthn does offer real advantages, I am concerned by how it reduces users to mere consumers, digital serfs to their technological overlords.
> But a secure password — i.e., a random value with 128 bits of entropy (such as a random 28-letter string) known only to the two parties to an authentication — is not rubbish.
No, they're still rubbish. Even if you make them 256 bit, passwords are bearer tokens which are reused across multiple authentications, which makes them replayable (if intercepted on the client, in transit, or server-side), phishable, social engineerable etc.
> There is the very minimum amount of protocol necessary: one party asks for it; the other party provides it.
And that's unfortunately too little protocol to be secure for repeated authentications.
> [...] principally due to no longer being a shared secret [...]
No, that's not the most important part of WebAuthN. You could get most of the benefits, i.e. phishing and social engineering resistance, from running it as a symmetric encryption protocol as well. Asymmetric keys "only" make server-side storage less sensitive (in the same way that hashing does for regular passwords).
> The end user can pick his own software to manage his passwords, or none at all (a piece of paper in a wallet is remarkably secure) and the relying party to has no ability to approve or disapprove.
The same is true for WebAuthN! (The only counterpoint here is attestation, but that is no longer a thing ever since Apple and Google introduced cloud synchronization for their credentials.) The difference is that you now need at least some software, because the calculations are too difficult to do on pen and paper.
> I am concerned by how it reduces users to mere consumers, digital serfs to their technological overlords.
Then... just don't do that! There are several open source implementations FIDO for you to choose from at this point.
The assumption that only one party knows the password is not always (maybe even usually) incorrect. Plenty of sites store the password in plain text or hash on the server side. Meaning it's very possible for both parties to know it.
There are some hairy edge cases during registration that many get wrong. (At least GitHub and google had this bug) that if create() returns but the passkey never reaches the server due to bad networking conditions that your password manager thinks it can log in but the server never recorded the passkey for the user. Basically there is no transactionality and you can get in a split brain situation where your password manager and your server don't agree and it's very confusing for end users.
This is an excellent write-up that finally motivated me to try to understand the mess that was left behind as new standards kept being layered on top of each other.
Given the requirement for discoverable credentials and sync, truly open/independent passkey implementations seem impossible/impractical. For example, you couldn't just have a set of Trezor-style devices that you load with the same seed and use that as your passkey without syncing the "discoverable" part of the credentials through some kind of cloud service. (The cloud service wouldn't need to be trusted with the actual keys, but you couldn't operate without it.)
As a result, it looks like you can essentially choose which ecosystem you want to lock yourself into...
With authenticatorAttachment, sites have been given a convenient foot-gun to make sure no single setup actually works for all sites, and with both the discoverable and non-discoverable credentials supported, inconsistency in the login flow for maximum confusion is guaranteed.
Add to it that this is like the 4th or 5th iteration of a standard in the field in about 10 years, and there's endless opportunity to get locked out because providers migrated from one standard (or buggy implementation) to another, or start setting things up only for the 6th standard to obsolete what you had (again, potentially locking you out).
And then people are surprised that users stick with passwords.
There is no technical requirement for discoverable credentials in most scenarios.
Sure, not having to type your username is nice, but I'll gladly still do that if it allows "passphrase-based paper-restore-able authenticators" such as the one you describe. (I have one of these, in fact!)
Many services I use that do support WebAuthN allow either variant to be used (i.e. they'll prefer discoverable credentials but will work just fine with non-discoverable ones), and arguably that should be how almost everybody ought to implement it.
Unfortunately, at least as many other services completely botch it, e.g. by making discoverable credentials mandatory, by allowlisting browsers (e.g. Paypal), allowlisting authenticators (e.g. my government's e-signature platform), or by using them in a functionally braindead way (e.g. Amazon, who for completely unfathomable reasons still requires TOTP behind WebAuthn, i.e. they replace the password with it, not the second factor).
So far I haven't noticed a strong trend towards enforcing discoverable credentials, but let's please name and shame everybody doing that. It's completely unnecessary.
Even the closed-system solution pose problems. I think it didn't get much airtime, but when Chrome switched their approach to save passwords, a lot of users lost access to their accounts. A case where a feature wasn't sensibly discontinued.
The workaround now isn't using passkeys, something few people understand. Instead most seem to be migrating to an external password managers. Honestly, I don't have many arguments against this as these at least generate save passwords. There are many advantages to this approach.
I believe moving forward, sticking to passwords might indeed be more viable. I think explaining users to upload their public ssl key is safer and more universal at this point.
I use password as main auth method for everything (via a pw manager) - but then I often add passkey or similar for convenience.
If I get locked out I still have the trad method as fallback; for me that’s the best of both worlds.
If you don’t offer password as method I will not use your service.
The worst are those that only offer code via email/sms or social login - miss me with that …
To me, they're an annoying half-measure: Not phishing/MITM resistant, yet annoying to use in practice.
I'll still take them over SMS-OTP any day, but admittedly even that at least offers some technical benefits over TOTP, e.g. in that the relying party can tell me what I am consenting to in the message ("by entering this code, you approve a payment of $1000 to evilshop.com").
2 factor authentication using 2 simple mechanisms is great.
Password for most cases. And then in high value things, ask me for 2FA. For things like banks and anything money related, SMS 2FA already exists and is good enough. For normal websites, uncommon yet important actions, such as logging in (everyone can use long lived sessions these days), repo deletion on GitHub, etc, ask for me for 2FA.
TOTP is also a really nice mechanism, especially in authenticator apps today that can backup your keys to cloud storage.
I know "SMS" and "backup keys to cloud storage" gets the security folks off their chairs, but outside a theoretical setting they're both a perfectly good tradeoff.
Just like every other piece on passkeys it does not justify them, at all.
Passwords have problems, but less than putting all authentication secrets in a single basket or ecosystem is (which is what big tech fundamentally wants).
Passkeys are a solution to a manufactured problem, and keeps getting pushed because it is a useful big tech honey trap that solidifies their user's captivity in their ecosystems.
KeePassXC has support. Many people use Vaultwarden. And so on.
Also, end users are already locked into Chrome and Safari (and Meta's webview and even worse fates).
Passkeys right now has upsides and downsides, like all technology.
I think they are both too complex/clunky on the data/spec/API side, and not complex enough on the UX/lifecycle side. But likely both will evolve based on the usage patterns that get solidified.
> KeePassXC has support. Many people use Vaultwarden. And so on.
It doesn’t matter if other authenticators could work if a relying party refuses to allow its users to use them.
> Also, end users are already locked into Chrome and Safari …
Not this end user; I am typing this in Firefox right now. Not coincidentally, WebAuthn is yet another bit of complexity making it slightly more difficult to implement a browser. From the perspective of the big tech companies, end users aren’t expected to write software, or to run anything the big tech companies haven vetted.
This is an extremely bad take. Webauthn and Passkeys do not necessitate handing over control to "big tech". They are standards implemented by open source projects as well as megacorps. Webauthn offers substantially better security than passwords, which we should all be moving away from by now.
Disclaimer; I work in security so my opinions are informed by actually knowing what I'm talking about.
It might provide more security but no, more security isn't the only metric when it comes to user facing stuff like this. If it was some implementation detail in a b2b service sure. But there are a lot more variables to take into account than just "how secure it is". As a trivial example, being able to recover an account is insecure by definition, yet is almost always necessary for any user created accounts.
Appeal to authority does not make a good argument.
We have witnessed the user capturing playbook of big tech for decades at this point. Ignoring what they are doing at this point is naive at best, malice at worst.
By enabling relying parties to blacklist or whitelist the devices their users are allowed to use.
It’s one more brick in the wall preventing general-purpose computing. Want to authenticate to Banana Computers? Well, you have to use one of their oDevices, because they will not let you use a RoboPhone to store your passkeys.
You seem to be thinking of attestation, which is not a thing anymore with at least Apple's and Google's implementation. (They both had it for their non-synchronizing device-bound authenticators, but have heavily or even entirely rolled that back in favor of passkeys.)
And since any solution excluding either of these is a non-starter, ironically the passkey push has made WebAuthN more open when it comes to client choice.
So while I agree that Apple and Google not allowing passkey exports (yet; I am cautiously optimistic that they'll eventually be pushed to offer that too) runs the risk of locking in non-sophisticated users, the future is looking very bright for everybody posting here at least.
Looks like an amazing resource for webauthn. Currently diving into this so it comes at a nice time for me.
But it's also great advertising against WebAuthn. Hard to believe that this kind of complexity is needed, but as with OpenID Connect it feels like enterprise interests are running the ship, not end-users. Ease of implementation seems like a non-goal.
Much of the specs were created behind closed doors and never done in a way where we could have had outside input. They're completely corporate driven and designed to control users not empower them.
(nb. I'm not saying the folks were easy to work with or super open to discussion, but it was not some clandestine black kitchen where it was cooked up.)
The working group is definitely quite corporate-driven – just look at who's most active in it! – and has made some bad decisions in the past (my favorite example being [1], which effectively either breaks the hardware authenticator experience for passkeys or helps Yubico sell more/higher capacity Yubikeys, depending on how you look at it).
But I agree that one thing you can't accuse them of is not operating in the open. While I don't agree with some of their decisions, discussing feedback in Github issues as well as on public mailing lists is probably as transparent as it gets.
It interested me how quickly all of my auth methods started to include "pick the right one of three presented numbers" tests after TOTP got widespread. I'm guessing there is some replay method which they wanted to prevent? This is distinct from in protocol large random value challenges, it must be to ensure a Hooman, or very numerate dog is actually present.
TOTP codes are phishable and repayable in real-time - both via web (visiting the wrong site which asks for a TOTP and relays it within a few seconds), and via social engineering over the phone (give us one of the codes to prove it's you and we can keep your account safe).
Adding number matching or similar helps ensure that the same user is initiating the session as is approving it - an issue when people discovered that Microsoft (among others) would do push messages to authenticate a login, and that users (if spammed late at night with constant requests), would often eventually hit allow to stop the notifications.
Pick the right number is not secure (enough), unfortunately - MFA exhaustion leads to users hitting one of three at random in an attempt to "make the notifications stop" (that are, naturally, being spammed by the attacker with a password but no mfa).
The attacker just has to spam them a few dozen times to get the victim to pick the right one at random and let the attacker in.
This is why it's switched on good platforms to "type in the number you see", which mitigated this.
That's slightly better against people essentially accidentally letting attackers in, but still completely phishable by e.g. tech support scammers.
The big advantage of WebAuthN is that (at least for sane implementations, including all I've seen) there just is no way to enter an attacker-provided number and/or supply a displayed code to an attacker.
Can anyone recommend a good dummy passkey provider to use when developing and testing RESTful authentication services that will rely on WebAuthn? Every example that I've seen online for interacting with a WebAuthn service assumes that you're working within the context of the browser and can use the Navigator APIs.
I like to use regular ol' cURL when testing out API endpoints, and it would be great if there were some kind of dummy CLI program that I could use to generate the WebAuthn key agreements and materials.
There isn't even a non-JavaScript way to use WebAuthn, let alone a non-browser way to use it. You could manually rewrite the JS for each site into curl calls or something I suppose.
I've always wanted to write a serverless OIDC provider/SAML IdP but got stymied by the WebAuthn standards, which don't seem to be written for normal people. :( But this e-book looks like it might have enough actual code interleaved with exposition to serve as more than just a high-level intro.
Adam Langley is probably one of the most gifted teachers when it comes to explaining cryptography concepts. Very clear, concise, precise, and makes it simple enough for me to follow without getting my neurons all knotted up.
OIDC providers are surprisingly NOT complicated! I created one to implement single sign-on with AWS, and it ended up being only around 200 lines of code in Go. All you need to do is create a JSON blob that is signed by a public key that is known to the consumer of the IDP.
> 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.
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
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.
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.
> I don't give a fuck if other people can't manage secure passwords.
Sure you do. When your local tax office / hospital / large data holder of your personal data has an administrative interface that only uses passwords, then the administrator gets fished and your identity stolen, suddenly you care a great deal.
That seems like a separate problem, since no authentication mechanism can somehow force a competence floor onto your local government office. Even if passkeys become the industry standard (or even required by law) your local government office will always rise to the challenge to lose your data, leak your data, sell your data, etc.
Phishing isn't a competence issue. This is well studied. In practice, even security practitioners trained to be vigilant against phishing attacks fall to targeted ("spear") phishing attacks of suitable sophistication; that's the impetus behind phishing-proof authenticators like U2F and WebAuthn.
I work in the security space and fell victim to an internal campaign as they sent a very enticing looking email at a point where I was on leave and my grandfather just passed.
You simply cannot know what mindset youll be in when you get phished :)
Edit: To clarify i was itching to work because it helps distract me from the reality that someone so dear to me was gone forever. I didnt want to cancel leave though because my output would have been absolutely turdy
Problem is that passkeys aren't resilient enough to loss of the authenticator device, which means a fallback flow is always made available, that is vulnerable to phishing/MITM/social engineering.
This is even more pronounced thanks to the efforts to roll out passkeys to the masses. Most of them don't understand what they're getting into and are most likely gonna get themselves locked out quite quickly, which may mean recovery flows need to actually become more relaxed than they currently are.
I'm not interested in litigating the broader question of Passkey-only login setups, only in spelling out why the field cares so much about phishing-resistant authenticators, which password managers and random passwords do not provide.
Can confirm, I know all about cryptography and security and the things, and I still got phished for a bunch of cryptocurrency. The only thing that saved me is that it was in a hardware wallet, so it was physically impossible to steal. Otherwise I was ready to happily paste my private key into the (official-looking) form and domain.
Ah you got me, though I don't think it changes that much.
Even with an online 'form' (presumably a phishing page) I don't understand why anyone would ever upload private keys for their wallets.
In the case of exchanges, users typically don't get access to the private key for the wallets anyway, so pretending to be an exchange to phish for something the victim can't even provide wouldn't make sense.
In the case of a local wallet, the whole purpose is personal ownership of the coins—which obviously becomes moot when sending the private key to some random person—so I don't see why a user would upload them in this circumstance either.
Though yes, the situation is certainly more understandable than GP posting private keys to an online 'forum' ;)
There's overwhelming empirical and anecdata evidence people make mistakes and fall for phishing. If that doesn't change your mind that much, it's not obvious what reasonably could.
Keys can be symmetric or asymmetric depending on the algorithm.
From the standpoint of a non-technical user, they're not any different in nature; a password and a private key are both just strings that give full access to your account. One is easier to remember (password), one is harder to remember (key). The one that is harder to remember usually ends up in a Google doc, iCloud, or saved as a text file.
Most implementations throw about 20 "recovery codes" at you and at the absolute fucking worst possible moment while the user is trying to do something urgent, they say "save these in a secure place right now".
It's not 1, but 20 passwords that ALL give access to your account. Where do you think those codes go?
They are not only phishable, but they usually end up in a Google doc, screenshotted and pasted to Notion, or some other insecure place.
Ssh keys are files that can be moved easily from device to device. That's very different to using e.g. your proprietary macbook internals as your login key. Completely different lock-in.
You can just enroll multiple keys from different devices, just like you do with SSH, that's the recommended way. But even then, there are software implementations of WebAuthn, like 1Password. You can then use the local TPM as a "last mile" authentication mechanism to quickly and effectively unlock your local encrypted password database and then get the needed key material to do WebAuthn. I use this across all my devices e.g. to login to GitHub, even on my iPhone.
You could accomplish something fairly similar to this for SSH keys actually (an encrypted sync layer + deriving master keys from a local trusted source), but I don't think anyone has done this to the same level of polish.
A passkey is a synced, discoverable WebAuthn credential. While many implementations protect the private keys with additional security measures like secure enclaves or TPMs, it's not required. If you want to use an implementation that doesn't use those types of lock-ins, even when they're there to protect your credentials, you can. Multiple software-only implementations exist.
> Consider passkeys as a standardized interface for password managers.
I have not followed WebAuthn spec for a while but I vaguely remember that the spec discouraged software-only authenticators.
Which made me feel like WebAuthn is yet another attempt to take the power from users and even states and concentrate it in the hands of a few multinationals controlled by US government.
Pretty much what happened to Certificate Authorities and the push to use HTTPS everywhere.
Of course there are benefits to HTTPS Everywhere and to passwordless authentication.
But they do not outweight concerns over the digital autonomy of my country.
For ordinary websites none of the existing platforms support WebAuthn attestation AFAIK, because the spec for attestation was not designed with key synchronization in mind, which is a key use case; otherwise, basic features like Keychain synchronization via iCloud would not work and the whole thing would be DOA. Synchronization is widely considered to be a core necessity to match the functionality of existing password managers.
I believe you can enforce attestation using MDM and a custom app as far as I'm aware. But for general people using Safari or whatever, you can't request any kind of device attestation.
1Password supports passkeys, and I am sure that others do as well.
Given the convenience factor (no extra install), I imagine that device/platform passkeys to be the most popular, but there should be no problem with using alternatives.
If the passkey protocol didn't support attestation, then that would be true. But since it does, passkeys aren't as good, since I can't make my own backups of them.
You're confused. You can use software that doesn't provide backups or clear exports, but attestation is not supported for any widely used websites or WebAuthn software because it defeats synchronization, something pretty much everyone widely considers to be a benefit. It would for example completely negate the ability to synchronize passkeys over something like iCloud, whether or not it had the ability to export keys in a standardized format. Attestation is basically a boondoggle solely for corporations with device management policies, so they can use a standard protocol/framework at the app layer while still enforcing stuff they already enforce.
The amount of people in this thread who don't understand the very basics of this stuff is a pretty good counterexample to the common trope they somehow "know better." I kind of doubt that when many people here can't even get the basics straight.
Generally attestation is not supported outside of enterprise contexts and Apple for example doesn't support it without mobile device management policies being applied to the device.
You can make your own backups of passkeys from your password manager.
I believe you are confusing ones that are stored in software or syncable (Passkeys) with the hardware backed credentials (platform authenticators).
> I believe you are confusing ones that are stored in software or syncable (Passkeys) with the hardware backed credentials (platform authenticators).
The problem is that the protocol allows websites to require use of the latter. If the two were indistinguishable to the website, then passkeys would be a good thing.
I don't believe there's any (public, stable) implementations of it yet, but Secure Credentials Exchange will let you export, transfer, and backup passkeys
That lets the megacorps make backups for me, but it doesn't let me make my own backups, because they'll only encrypt them to each others' public keys, not mine.
Passkeys and 2FA recovery codes are all just shitty replacements for passwords.
Fight me. Grandmas and Joes end up putting these recovery codes in a Google doc because they don't know what the hell else to do with them. That is NOT more secure.
Hell, even try explaining the difference between the "secret key" and the "password" in 1password to a non-technical person. It's impossible.
The very first sentence is:
> Passwords are rubbish.
Hard, hard disagree. They’re really not. Password reuse is rubbish. Passwords human beings can remember are rubbish. But a secure password — i.e., a random value with 128 bits of entropy (such as a random 28-letter string) known only to the two parties to an authentication — is not rubbish.
There is the very minimum amount of protocol necessary: one party asks for it; the other party provides it.
The end user can pick his own software to manage his passwords, or none at all (a piece of paper in a wallet is remarkably secure) and the relying party to has no ability to approve or disapprove.
I do agree that WebAuthn offers very real improvements over passwords (principally due to no longer being a shared secret), but it makes things worse for the users in a few ways. For one, the ability of relying parties to blacklist or whitelist authenticators tramples on the user’s freedom to use the software he wants. Attestation keys and enterprise attestation are user-hostile: users and servers are no longer equal parties.
And finally, the user experience of passkeys with, say, a phone-based authenticator is miserable: one must interrupt one’s computer usage, pick up the phone, unlock the phone, open the notification and unlock the app, then put the phone down.
All in all, while WebAuthn does offer real advantages, I am concerned by how it reduces users to mere consumers, digital serfs to their technological overlords.
> But a secure password — i.e., a random value with 128 bits of entropy (such as a random 28-letter string) known only to the two parties to an authentication — is not rubbish.
No, they're still rubbish. Even if you make them 256 bit, passwords are bearer tokens which are reused across multiple authentications, which makes them replayable (if intercepted on the client, in transit, or server-side), phishable, social engineerable etc.
> There is the very minimum amount of protocol necessary: one party asks for it; the other party provides it.
And that's unfortunately too little protocol to be secure for repeated authentications.
> [...] principally due to no longer being a shared secret [...]
No, that's not the most important part of WebAuthN. You could get most of the benefits, i.e. phishing and social engineering resistance, from running it as a symmetric encryption protocol as well. Asymmetric keys "only" make server-side storage less sensitive (in the same way that hashing does for regular passwords).
> The end user can pick his own software to manage his passwords, or none at all (a piece of paper in a wallet is remarkably secure) and the relying party to has no ability to approve or disapprove.
The same is true for WebAuthN! (The only counterpoint here is attestation, but that is no longer a thing ever since Apple and Google introduced cloud synchronization for their credentials.) The difference is that you now need at least some software, because the calculations are too difficult to do on pen and paper.
> I am concerned by how it reduces users to mere consumers, digital serfs to their technological overlords.
Then... just don't do that! There are several open source implementations FIDO for you to choose from at this point.
The assumption that only one party knows the password is not always (maybe even usually) incorrect. Plenty of sites store the password in plain text or hash on the server side. Meaning it's very possible for both parties to know it.
Ignore this, I misread what the author above wrote.
There are some hairy edge cases during registration that many get wrong. (At least GitHub and google had this bug) that if create() returns but the passkey never reaches the server due to bad networking conditions that your password manager thinks it can log in but the server never recorded the passkey for the user. Basically there is no transactionality and you can get in a split brain situation where your password manager and your server don't agree and it's very confusing for end users.
https://github.com/w3c/webauthn/issues/2038
They apparently came up with a fix for this using something called Signals API but I don't think any browser implemented that yet.
Just wanted to highlight that this part of the UX is hairy and hard to get right
Chrome on desktop did: https://developer.chrome.com/docs/identity/webauthn-signal-a...
Nice seeing you here! :)
This is an excellent write-up that finally motivated me to try to understand the mess that was left behind as new standards kept being layered on top of each other.
Given the requirement for discoverable credentials and sync, truly open/independent passkey implementations seem impossible/impractical. For example, you couldn't just have a set of Trezor-style devices that you load with the same seed and use that as your passkey without syncing the "discoverable" part of the credentials through some kind of cloud service. (The cloud service wouldn't need to be trusted with the actual keys, but you couldn't operate without it.)
As a result, it looks like you can essentially choose which ecosystem you want to lock yourself into...
With authenticatorAttachment, sites have been given a convenient foot-gun to make sure no single setup actually works for all sites, and with both the discoverable and non-discoverable credentials supported, inconsistency in the login flow for maximum confusion is guaranteed.
Add to it that this is like the 4th or 5th iteration of a standard in the field in about 10 years, and there's endless opportunity to get locked out because providers migrated from one standard (or buggy implementation) to another, or start setting things up only for the 6th standard to obsolete what you had (again, potentially locking you out).
And then people are surprised that users stick with passwords.
There is no technical requirement for discoverable credentials in most scenarios.
Sure, not having to type your username is nice, but I'll gladly still do that if it allows "passphrase-based paper-restore-able authenticators" such as the one you describe. (I have one of these, in fact!)
Many services I use that do support WebAuthN allow either variant to be used (i.e. they'll prefer discoverable credentials but will work just fine with non-discoverable ones), and arguably that should be how almost everybody ought to implement it.
Unfortunately, at least as many other services completely botch it, e.g. by making discoverable credentials mandatory, by allowlisting browsers (e.g. Paypal), allowlisting authenticators (e.g. my government's e-signature platform), or by using them in a functionally braindead way (e.g. Amazon, who for completely unfathomable reasons still requires TOTP behind WebAuthn, i.e. they replace the password with it, not the second factor).
So far I haven't noticed a strong trend towards enforcing discoverable credentials, but let's please name and shame everybody doing that. It's completely unnecessary.
Even the closed-system solution pose problems. I think it didn't get much airtime, but when Chrome switched their approach to save passwords, a lot of users lost access to their accounts. A case where a feature wasn't sensibly discontinued.
The workaround now isn't using passkeys, something few people understand. Instead most seem to be migrating to an external password managers. Honestly, I don't have many arguments against this as these at least generate save passwords. There are many advantages to this approach.
I believe moving forward, sticking to passwords might indeed be more viable. I think explaining users to upload their public ssl key is safer and more universal at this point.
I use password as main auth method for everything (via a pw manager) - but then I often add passkey or similar for convenience. If I get locked out I still have the trad method as fallback; for me that’s the best of both worlds.
If you don’t offer password as method I will not use your service. The worst are those that only offer code via email/sms or social login - miss me with that …
And then people are surprised that users stick with passwords.
IMHO that and a TOTP seems to be a sweet spot.
To me, they're an annoying half-measure: Not phishing/MITM resistant, yet annoying to use in practice.
I'll still take them over SMS-OTP any day, but admittedly even that at least offers some technical benefits over TOTP, e.g. in that the relying party can tell me what I am consenting to in the message ("by entering this code, you approve a payment of $1000 to evilshop.com").
Except that TOTP codes are MitM phishable. U2F with its URL-checking (via browser cooperation) is needed.
Yep.
2 factor authentication using 2 simple mechanisms is great.
Password for most cases. And then in high value things, ask me for 2FA. For things like banks and anything money related, SMS 2FA already exists and is good enough. For normal websites, uncommon yet important actions, such as logging in (everyone can use long lived sessions these days), repo deletion on GitHub, etc, ask for me for 2FA.
TOTP is also a really nice mechanism, especially in authenticator apps today that can backup your keys to cloud storage.
I know "SMS" and "backup keys to cloud storage" gets the security folks off their chairs, but outside a theoretical setting they're both a perfectly good tradeoff.
Just like every other piece on passkeys it does not justify them, at all.
Passwords have problems, but less than putting all authentication secrets in a single basket or ecosystem is (which is what big tech fundamentally wants).
Passkeys are a solution to a manufactured problem, and keeps getting pushed because it is a useful big tech honey trap that solidifies their user's captivity in their ecosystems.
Those are pretty strong claims.
KeePassXC has support. Many people use Vaultwarden. And so on.
Also, end users are already locked into Chrome and Safari (and Meta's webview and even worse fates).
Passkeys right now has upsides and downsides, like all technology.
I think they are both too complex/clunky on the data/spec/API side, and not complex enough on the UX/lifecycle side. But likely both will evolve based on the usage patterns that get solidified.
> KeePassXC has support. Many people use Vaultwarden. And so on.
It doesn’t matter if other authenticators could work if a relying party refuses to allow its users to use them.
> Also, end users are already locked into Chrome and Safari …
Not this end user; I am typing this in Firefox right now. Not coincidentally, WebAuthn is yet another bit of complexity making it slightly more difficult to implement a browser. From the perspective of the big tech companies, end users aren’t expected to write software, or to run anything the big tech companies haven vetted.
This is an extremely bad take. Webauthn and Passkeys do not necessitate handing over control to "big tech". They are standards implemented by open source projects as well as megacorps. Webauthn offers substantially better security than passwords, which we should all be moving away from by now.
Disclaimer; I work in security so my opinions are informed by actually knowing what I'm talking about.
It might provide more security but no, more security isn't the only metric when it comes to user facing stuff like this. If it was some implementation detail in a b2b service sure. But there are a lot more variables to take into account than just "how secure it is". As a trivial example, being able to recover an account is insecure by definition, yet is almost always necessary for any user created accounts.
> Webauthn and Passkeys do not necessitate handing over control to "big tech".
Attestation enables a relying party to deny users the right of using their own software or devices. That hands over control.
Apple and Google discontinued attestation when they introduced passkeys. It's gone.
There are still lots of problems with passkeys, but it's worth staying up to date if you want to contribute to that discussion.
Appeal to authority does not make a good argument.
We have witnessed the user capturing playbook of big tech for decades at this point. Ignoring what they are doing at this point is naive at best, malice at worst.
100% agree. Passwords + OTPs are the best solution, IMO. No big tech can control this, and it's easy to keep a grasp on all the credentials we have.
WebAuthn? No, thanks.
How does big tech exert control over your usage of WebAuthn?
By enabling relying parties to blacklist or whitelist the devices their users are allowed to use.
It’s one more brick in the wall preventing general-purpose computing. Want to authenticate to Banana Computers? Well, you have to use one of their oDevices, because they will not let you use a RoboPhone to store your passkeys.
You seem to be thinking of attestation, which is not a thing anymore with at least Apple's and Google's implementation. (They both had it for their non-synchronizing device-bound authenticators, but have heavily or even entirely rolled that back in favor of passkeys.)
And since any solution excluding either of these is a non-starter, ironically the passkey push has made WebAuthN more open when it comes to client choice.
So while I agree that Apple and Google not allowing passkey exports (yet; I am cautiously optimistic that they'll eventually be pushed to offer that too) runs the risk of locking in non-sophisticated users, the future is looking very bright for everybody posting here at least.
Looks like an amazing resource for webauthn. Currently diving into this so it comes at a nice time for me.
But it's also great advertising against WebAuthn. Hard to believe that this kind of complexity is needed, but as with OpenID Connect it feels like enterprise interests are running the ship, not end-users. Ease of implementation seems like a non-goal.
WebAuthn and passkeys are a disaster.
Much of the specs were created behind closed doors and never done in a way where we could have had outside input. They're completely corporate driven and designed to control users not empower them.
I agree. I will not use them, not as a user, nor as a developer.
Ah yes the closed doors of the world wide web consortium.
https://lists.w3.org/Archives/Public/public-webauthn/
(nb. I'm not saying the folks were easy to work with or super open to discussion, but it was not some clandestine black kitchen where it was cooked up.)
The working group is definitely quite corporate-driven – just look at who's most active in it! – and has made some bad decisions in the past (my favorite example being [1], which effectively either breaks the hardware authenticator experience for passkeys or helps Yubico sell more/higher capacity Yubikeys, depending on how you look at it).
But I agree that one thing you can't accuse them of is not operating in the open. While I don't agree with some of their decisions, discussing feedback in Github issues as well as on public mailing lists is probably as transparent as it gets.
[1] https://github.com/w3c/webauthn/issues/1822
It interested me how quickly all of my auth methods started to include "pick the right one of three presented numbers" tests after TOTP got widespread. I'm guessing there is some replay method which they wanted to prevent? This is distinct from in protocol large random value challenges, it must be to ensure a Hooman, or very numerate dog is actually present.
TOTP codes are phishable and repayable in real-time - both via web (visiting the wrong site which asks for a TOTP and relays it within a few seconds), and via social engineering over the phone (give us one of the codes to prove it's you and we can keep your account safe).
Adding number matching or similar helps ensure that the same user is initiating the session as is approving it - an issue when people discovered that Microsoft (among others) would do push messages to authenticate a login, and that users (if spammed late at night with constant requests), would often eventually hit allow to stop the notifications.
Pick the right number is not secure (enough), unfortunately - MFA exhaustion leads to users hitting one of three at random in an attempt to "make the notifications stop" (that are, naturally, being spammed by the attacker with a password but no mfa).
The attacker just has to spam them a few dozen times to get the victim to pick the right one at random and let the attacker in.
This is why it's switched on good platforms to "type in the number you see", which mitigated this.
That's slightly better against people essentially accidentally letting attackers in, but still completely phishable by e.g. tech support scammers.
The big advantage of WebAuthN is that (at least for sane implementations, including all I've seen) there just is no way to enter an attacker-provided number and/or supply a displayed code to an attacker.
Can anyone recommend a good dummy passkey provider to use when developing and testing RESTful authentication services that will rely on WebAuthn? Every example that I've seen online for interacting with a WebAuthn service assumes that you're working within the context of the browser and can use the Navigator APIs.
I like to use regular ol' cURL when testing out API endpoints, and it would be great if there were some kind of dummy CLI program that I could use to generate the WebAuthn key agreements and materials.
What exactly are you trying to test? Is there even a non-browser standard/protocol for using WebAuthN (which is a web standard, after all)?
There isn't even a non-JavaScript way to use WebAuthn, let alone a non-browser way to use it. You could manually rewrite the JS for each site into curl calls or something I suppose.
I've always wanted to write a serverless OIDC provider/SAML IdP but got stymied by the WebAuthn standards, which don't seem to be written for normal people. :( But this e-book looks like it might have enough actual code interleaved with exposition to serve as more than just a high-level intro.
Adam Langley is probably one of the most gifted teachers when it comes to explaining cryptography concepts. Very clear, concise, precise, and makes it simple enough for me to follow without getting my neurons all knotted up.
Agreed, I implemented TLS key pinning for a project at Okta using one of Adam's blog posts
Yes, the WebAuthn spec is pretty unreadable. Every time I open it I feel like I’m lost in a maze of twisty hyperlinks, all alike.
OIDC providers are surprisingly NOT complicated! I created one to implement single sign-on with AWS, and it ended up being only around 200 lines of code in Go. All you need to do is create a JSON blob that is signed by a public key that is known to the consumer of the IDP.
I'll need to do a write-up for it.
> 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.
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
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.
That's a pretty neat solution. I like that idea.
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.
Storing the passkeys on a device protected by a PIN is an option too. Example: T2F2-PIN+ Release3 by Token2 can store 300 passkeys.
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.
Just use a password manager that doesn't sync by itself then
https://keepassxc.org/docs/KeePassXC_UserGuide#_passkeys
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.
> 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).
You can, it’s part of CTAP2 and various apps like Yubico Authenticator are available to do it.
It’s not user-friendly, but it is possible.
There's no browser extension available for Safari: https://keepassxc.org/docs/KeePassXC_GettingStarted#_setup_b...
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.
> The vendors claim that this is to make phishing impossible
They do? I don't see how, since non-discoverable WebAuthN credentials make phishing just as impossible.
The only thing discoverable credentials allow on top of non-discoverable ones is avoiding having the user type in their username or email address.
yes, that is for "usernameless" login, in addition to passwordless. Does not increase security, improves usability a bit
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.
[flagged]
> I don't give a fuck if other people can't manage secure passwords.
Sure you do. When your local tax office / hospital / large data holder of your personal data has an administrative interface that only uses passwords, then the administrator gets fished and your identity stolen, suddenly you care a great deal.
That seems like a separate problem, since no authentication mechanism can somehow force a competence floor onto your local government office. Even if passkeys become the industry standard (or even required by law) your local government office will always rise to the challenge to lose your data, leak your data, sell your data, etc.
Phishing isn't a competence issue. This is well studied. In practice, even security practitioners trained to be vigilant against phishing attacks fall to targeted ("spear") phishing attacks of suitable sophistication; that's the impetus behind phishing-proof authenticators like U2F and WebAuthn.
Phishing is a technology issue, not a user issue.
I work in the security space and fell victim to an internal campaign as they sent a very enticing looking email at a point where I was on leave and my grandfather just passed.
You simply cannot know what mindset youll be in when you get phished :)
Edit: To clarify i was itching to work because it helps distract me from the reality that someone so dear to me was gone forever. I didnt want to cancel leave though because my output would have been absolutely turdy
Problem is that passkeys aren't resilient enough to loss of the authenticator device, which means a fallback flow is always made available, that is vulnerable to phishing/MITM/social engineering.
This is even more pronounced thanks to the efforts to roll out passkeys to the masses. Most of them don't understand what they're getting into and are most likely gonna get themselves locked out quite quickly, which may mean recovery flows need to actually become more relaxed than they currently are.
I'm not interested in litigating the broader question of Passkey-only login setups, only in spelling out why the field cares so much about phishing-resistant authenticators, which password managers and random passwords do not provide.
Can confirm, I know all about cryptography and security and the things, and I still got phished for a bunch of cryptocurrency. The only thing that saved me is that it was in a hardware wallet, so it was physically impossible to steal. Otherwise I was ready to happily paste my private key into the (official-looking) form and domain.
> Otherwise I was ready to happily paste my private key into the (official-looking) form and domain.
Sorry, why would you ever disclose your private key to some online forum? I can't see a situation where it makes sense.
Clearly there's something I'm not thinking of, so I'm genuinely curious
I think you misread the word "form" as "forum" there.
Ah you got me, though I don't think it changes that much.
Even with an online 'form' (presumably a phishing page) I don't understand why anyone would ever upload private keys for their wallets.
In the case of exchanges, users typically don't get access to the private key for the wallets anyway, so pretending to be an exchange to phish for something the victim can't even provide wouldn't make sense.
In the case of a local wallet, the whole purpose is personal ownership of the coins—which obviously becomes moot when sending the private key to some random person—so I don't see why a user would upload them in this circumstance either.
Though yes, the situation is certainly more understandable than GP posting private keys to an online 'forum' ;)
I don't think it changes that much.
There's overwhelming empirical and anecdata evidence people make mistakes and fall for phishing. If that doesn't change your mind that much, it's not obvious what reasonably could.
Sure, but you're moving the goalposts. We're comparing a system that relies exclusively on passwords Vs one that relies on webauthn.
The operational competence of the dba is the same in both cases.
Or they store your password insecurely — plain text or merely “encrypted” with XOR.
I still see both of those regularly.
Everything boils down to some password or key (effectively a long password) access to some SQL instance.
Anything on top of that is just fluff. The database can still be compromised directly.
Keys are _not_ just long passwords. They're asymmetric. Feel free to steal any and all of my webauthn public keys.
Heck, here's one: "kty": "EC", "alg": "ECDSA_w_SHA256", "crv": "P-256", "x": "xYkEVgMClD28hXHn5JQjrgjRX3crmr0OhGiWKsLvxUY=", "y": "5lZZGFF6VrVubIHfRhGbvQBGpw6LcbP3/ZBVk7PqH0Y="
It's what you'd get if you somehow got into the db and decrypted it.
Now, do feel free to give me your nice symmetric secret password, since it's the same, yeah?
Keys can be symmetric or asymmetric depending on the algorithm.
From the standpoint of a non-technical user, they're not any different in nature; a password and a private key are both just strings that give full access to your account. One is easier to remember (password), one is harder to remember (key). The one that is harder to remember usually ends up in a Google doc, iCloud, or saved as a text file.
There's a difference between fluffy that's phishable (passwords) and fluff that isn't (webauthn).
Not all fluff is equal.
How is Webauth'n Crunch not phishable?
Most implementations throw about 20 "recovery codes" at you and at the absolute fucking worst possible moment while the user is trying to do something urgent, they say "save these in a secure place right now".
It's not 1, but 20 passwords that ALL give access to your account. Where do you think those codes go?
They are not only phishable, but they usually end up in a Google doc, screenshotted and pasted to Notion, or some other insecure place.
We're talking about webauthn, not recovery codes.
We have decades of supporting evidence that passwords are rubbish at this point.
Congratulations on being able to maintain good password habits yourself. It sounds like you already know how vanishingly rare that is.
and yet everyone recommends ssh keys over passwords. passkeys are just the ssh keys of the web
Ssh keys are files that can be moved easily from device to device. That's very different to using e.g. your proprietary macbook internals as your login key. Completely different lock-in.
You can just enroll multiple keys from different devices, just like you do with SSH, that's the recommended way. But even then, there are software implementations of WebAuthn, like 1Password. You can then use the local TPM as a "last mile" authentication mechanism to quickly and effectively unlock your local encrypted password database and then get the needed key material to do WebAuthn. I use this across all my devices e.g. to login to GitHub, even on my iPhone.
You could accomplish something fairly similar to this for SSH keys actually (an encrypted sync layer + deriving master keys from a local trusted source), but I don't think anyone has done this to the same level of polish.
You can do passkeys in software too:
https://keepassxc.org/docs/KeePassXC_UserGuide#_passkeys
A passkey is a synced, discoverable WebAuthn credential. While many implementations protect the private keys with additional security measures like secure enclaves or TPMs, it's not required. If you want to use an implementation that doesn't use those types of lock-ins, even when they're there to protect your credentials, you can. Multiple software-only implementations exist.
Until they start trying to enforce attestation. Then your only choice will be giving a large corporation control over your online access.
[dead]
> I don't give a fuck if other people can't manage secure passwords.
I infer that you use a password manager.
Consider passkeys as a standardized interface for password managers.
> Consider passkeys as a standardized interface for password managers.
I have not followed WebAuthn spec for a while but I vaguely remember that the spec discouraged software-only authenticators.
Which made me feel like WebAuthn is yet another attempt to take the power from users and even states and concentrate it in the hands of a few multinationals controlled by US government.
Pretty much what happened to Certificate Authorities and the push to use HTTPS everywhere.
Of course there are benefits to HTTPS Everywhere and to passwordless authentication.
But they do not outweight concerns over the digital autonomy of my country.
For ordinary websites none of the existing platforms support WebAuthn attestation AFAIK, because the spec for attestation was not designed with key synchronization in mind, which is a key use case; otherwise, basic features like Keychain synchronization via iCloud would not work and the whole thing would be DOA. Synchronization is widely considered to be a core necessity to match the functionality of existing password managers.
I believe you can enforce attestation using MDM and a custom app as far as I'm aware. But for general people using Safari or whatever, you can't request any kind of device attestation.
1Password supports passkeys, and I am sure that others do as well.
Given the convenience factor (no extra install), I imagine that device/platform passkeys to be the most popular, but there should be no problem with using alternatives.
If the passkey protocol didn't support attestation, then that would be true. But since it does, passkeys aren't as good, since I can't make my own backups of them.
You're confused. You can use software that doesn't provide backups or clear exports, but attestation is not supported for any widely used websites or WebAuthn software because it defeats synchronization, something pretty much everyone widely considers to be a benefit. It would for example completely negate the ability to synchronize passkeys over something like iCloud, whether or not it had the ability to export keys in a standardized format. Attestation is basically a boondoggle solely for corporations with device management policies, so they can use a standard protocol/framework at the app layer while still enforcing stuff they already enforce.
The amount of people in this thread who don't understand the very basics of this stuff is a pretty good counterexample to the common trope they somehow "know better." I kind of doubt that when many people here can't even get the basics straight.
Generally attestation is not supported outside of enterprise contexts and Apple for example doesn't support it without mobile device management policies being applied to the device.
You can make your own backups of passkeys from your password manager.
I believe you are confusing ones that are stored in software or syncable (Passkeys) with the hardware backed credentials (platform authenticators).
> I believe you are confusing ones that are stored in software or syncable (Passkeys) with the hardware backed credentials (platform authenticators).
The problem is that the protocol allows websites to require use of the latter. If the two were indistinguishable to the website, then passkeys would be a good thing.
I don't believe there's any (public, stable) implementations of it yet, but Secure Credentials Exchange will let you export, transfer, and backup passkeys
https://fidoalliance.org/specifications-credential-exchange-...
https://fidoalliance.org/specs/cx/cxp-v1.0-wd-20241003.html
That lets the megacorps make backups for me, but it doesn't let me make my own backups, because they'll only encrypt them to each others' public keys, not mine.
I do, so I have a working solution.
I am not migrating to something just because it's new.
My solution works for me. If it doesn't anymore, I'll see what I'll do.
Depending on the service I'll swallow the bitter pill and use another solution or simply not use the service anymore.
Every and any decision has consequences, on any side.
https://f8n-ipfs-production.imgix.net/QmaangUFNxGD6vRjnqzVnL...
Thank you, this made my day :)
Passkeys and 2FA recovery codes are all just shitty replacements for passwords.
Fight me. Grandmas and Joes end up putting these recovery codes in a Google doc because they don't know what the hell else to do with them. That is NOT more secure.
Hell, even try explaining the difference between the "secret key" and the "password" in 1password to a non-technical person. It's impossible.