I'm calling it now: if/when this really takes off, this will absolutely be used as a way to lock users into the platform (OS and/or browser). Even the vendors that have committed to being open about 3rd party integration will close that loophole. It will be done 'in the name of security', because, ostensibly, Microsoft/Apple can ensure the keys are stored 'more securely' or the sync is easier.
Having the keys in your PW manager of choice is worthless if your browser/OS won't play ball. Keeping all those logins locked inside Apple/Google/MS's garden is just too juicy of a 'sticky' platform lock-in to ignore. Besides, only nerds care about integration of other key storage platforms; 98% of users will just keep them in iCloud/Hello/Google, so maintaining the APIs to enable that integration will be on the chopping block of every Product Manager.
e.g. look at Google's Authenticator app. Once you add a TOTP secret, you can't get it back out. Only recently did they add the ability to sync, but only to other Android devices you own. Those keys are hidden forever, for your protection.
I would flip this argument around: if the only way to use passkeys effectively is to be locked into a single platform, then passkeys will never take off.
Login with Facebook has existed for years now, but not everybody with a Facebook account uses it, even if they can. Why? Because that vendor lock in means that people are discouraged from using it in all cases. Banks don’t want to use it. Other large websites don’t want to use it. Businesses don’t want to use it internally.
I think that there will be significant enough demand for 3rd party, open solutions that passkeys will succeed. If there isn’t that demand, then it will fail overall.
OAuth/OIDC flow through Facebook (or whoever) doesn't really have the same tight integration into the browser/OS that WebAuthn proposes, however. There's also no compelling reason for 'Website X' to support OIDC with Facebook/Google/Yahoo/other, because there's too many choices and if the provider of choice is down, your site is inaccessible to those users.
The major browsers and OSes already support WebAuthn, so it may be compelling for all 'Website Xs' to implement it, though the linked article presents a (dated) concern that they won't.
That's not the part I'm worried about: WebAuthn as a standard may work almost everywhere, but as a user, your ability to bounce around between browsers/OSes with your secrets coming with you may be restricted.
None of your observations strike true, perhaps you are assuming too much thought on the part of the average user. People use 'Login with FB' (and others) because it is convenient, there is nothing more to it. It's only a small fraction of the population that are aware that choose to avoid using it due to the potential for lockin.
Yeah the remark about businesses was more persuasive. Banks and other large B2C organisations are much more likely to care about commercial lock in and the compliance risks of using Facebook login than consumer users.
I have Facebook (albeit rarely used) and Google accounts. Many sites offer me the option to sign in with one or the other of those. I've used Google for Stack Exchange, but otherwise would never use these for anything. Both those companies know enough about me already.
For passkeys in particular, this theory would be more credible if it wasn't for the fact pretty much every password manager has planned support for them, and almost all of those same managers have been integrated with your browser's password manager APIs and the OS's secure auth mechanism. 1Password will use Face ID or Windows Hello Pin to unlock your vault, and then it will offer up the passkey credential, just like it does with your completely randomly generated password, today, the difference being you can't phish them or recover them from hacking websites. Like this theory just doesn't work as well when we basically have years of evidence suggesting the exact opposite thing, which is that both major browser vendors and password managers are interested in cooperation in order to achieve better user experience and security.
Plus the idea is predicated on the idea you can't just register another device. Passkeys, as a user auth model, pretty much require the ability for multiple devices to be tied to one account. Google has your passkey for site X? Log in, register a new passkey with 1Password, delete your old passkey. Done.
Sure, for now. If it ever reaches wide adoption, when Google/MS/Apple see only 2% of users use a 3rd party to store keys, why would they continue to maintain the ability to integrate? Especially if there's some advantage (lock in) to not doing so.
Multiple devices/key stores that don't sync are dead before they even get started. Almost no users are going to be willing to do that, and thus most websites won't bother to support it. How many websites today offer the ability to have multiple OTP options concurrently and/or allow you to only enable TOTP and disable email/SMS?
This will start out open and flexible to gain adoption, and then either through malice, laziness, or low adoption, the options that avoid lock in will be phased out.
It doesn't matter how many different things have support for passkeys. Because they let websites do "attestation" of them, it won't be long until every major website is only allowing logins with passkeys blessed by Microsoft, Apple, or Google.
I'm not familiar with all this, but when I run the demo page (https://webauthn.lubu.ch/_test/client.html) on macOS 13.4.1 with Safari (Firefox doesn't work) I get "none" for the apple attestation.
webauthn, as designed, can't be used to lock anybody into any authentication method, because the apps that use it should support adding as many different webauthn methods as you want. it only has the possibility to be a lock-in if you are restricted in the number of authentication methods you can add for a third-party service you want to authenticate to. and FWIW, apple and google both recommend supporting infinite passkeys, and have implemented that in their own webapps. any fearmongering about webauthn/fido/passkeys being a vendor lock-in is not backed up by current facts.
WebAuthn has a specific feature called “attestation” where an app can only accept keys from a specific vendor as verified by vendor-provided signatures (that the user agent cannot forge). I personally doubt it will be used for this kind of lock in (it’s currently mostly used by companies for internal authentication so they can make sure you only use the brand of WebAuthn keys issued by them) but it’s not technically infeasible with the current standard.
If you want to see an outside of the box use of the attestation feature, take a look at Cloudflare’s “Cryptographic Attestation of Personhood” [1]. Basically they use the attestation key to tie the WebAuthn challenge to a real vendor, so if spammers make their own fake WebAuthn keys they can block them wholesale. I’m sure some Cloudflare skeptics will jump in and point out all the ways that could be abused.
The problem is how you get those keys, rather, the results of crypto functions on those keys, back to the requesting website. That process, 'Client to Authenticator'[1] relies on the goodwill of the 'Clients', which for all intents and purposes are: Chrome, Safari, Edge, Firefox, Windows 10+, iOS, and Android.
Maybe they'll always support cross-platform USB/NFC keys (they probably will), but I don't want an external device(s), especially if I have to remember to set up multiple devices for every site to have redundancy.
> The problem is how you get those keys, rather, the results of crypto functions on those keys, back to the requesting website
Yes. Good thing there's an open standard called webauthn, supported by all the major vendors, that defines an interoperable way to get the result of those crypto functions back to the websites that need them.
The person you're replying to is clearly talking about the portability of the private key material across multiple, heterogeneous clients - which webauthn doesn't touch.
> webauthn, as designed, can't be used to lock anybody into any authentication method
It only supports HTTP as I understand it, and won't work for other protocols like SMTP or IMAP.
What does work, regardless of application level protocol is using TLS certifications on both the client and server side in combination with a username and password for authentication.
WebAuthn doesn’t even support HTTP technically. All of the communication between the relying party and the user agent is non-standard and is handled by JavaScript today.
I recently tried to import and old backup which contained a key I thought was obsolete. But didn't have any luck. My up to date authenticator couldn't read the 2 years old export.
I've very hastily made sure that all my backup keys are up to date afterwards...
Fair enough. I stopped using it right around the time (~2 years ago?) when they finally added the ability to do an export. At that time, the compelling reason to use alternative TOTP apps was the ability to sync the secrets. I assume this feature was driven mostly because of said alternatives, rather than goodwill for such a simple/obvious feature.
I always did & do save a copy of the QR code or, if provided, the BASE64ed key in my PW manager. I know I'm never locked in with TOTP: I can use anything (I've written the 10 lines of code, even) to generate the code, and it can be entered manually on any device that can display the site's login page by hitting 6 digit-keys. WebAuthn needs, at minimum, the browser to remain open to integration.
Not op, but my qr codes & strings are saved in a separate keypass database, saved in a different location & using different password (saved in my brain only).
Why would Apple, Google, Microsoft CEO want to go to congressional hearings and put a big stain on themselves for 2% market share? I think they just want to get rid of passwords because there are good people working there too and it is a pain to pay for support.
Pass managers have totp authenticators as well. I mean really, you can just sit back and have Apple do everything for you (built in totp) or the same with Google or you get 10+ pass managers to choose from, some are open source... This whole thing is rather paranoia as of now.
We must be crictical and watch out but the law is on our side:
It is theoretically possible for a dominant company to support a third-party technology or standard initially and then abandon it, which could potentially harm competition. This practice is known as "embrace, extend, extinguish" or "embrace, extend, and extinguish" (EEE). The term was coined during the Microsoft antitrust case in the late 1990s, where Microsoft was accused of using its market power to undermine competing technologies.
In the case of passkey technology or any other standard, if a dominant company were to initially support it, attract third-party developers and users, and then suddenly abandon or change the technology in a way that hampers compatibility or competition, it could potentially limit the options available to users and stifle innovation from other companies.
However, it's important to note that such practices can be subject to scrutiny and legal action under competition laws. Antitrust authorities, such as the DOJ and FTC, are responsible for investigating and addressing anti-competitive behavior. If there are indications that a company's actions are harming competition or violating antitrust laws, regulatory authorities may step in to assess the situation and take appropriate measures.
Yea but these days they will get some stupid fine like $30m which is a rounding error for these companies. Especially in the US where bribes are legal, and it has been proven over and over that the politicians will do whatever their corp overlords tell them to do.
I believe they would be then forced to open up, not just fines.
Free pass management is really a basic human right (or democracies can make them to be). I personally do not hate Apple, Google, Microsoft but they own 99% of OS I guess so if passkeys take off, they have to remain open.
I mean at least Europe and California (and the rest of the World that is not US) and even US citizens would back competition in pass management sector. What we really needed is a good Linux phone. Now I use Google stuff but I would change to full Linux+Proton I guess. They just announced their open source pass manager!
I am not saaying we should not be vigilant but I guess we are stronger than you might think (I mean we vs. a heterogenous not-really-oligopoly-us-os-providers).
Still sucks to add it to your app.
You pretty much have to use a library or you'll be maintaining all of the device level quirks yourself. OIDC has the same problem where the standard was too loosey goosey and didn't provide a true standard interface, leading to some special handlings for providers.
IMO, folks who write standards need to write them with the best interests of the developers who will be integrating it, not the service providers.
My personal experience with certified implementations is that they still tend to be not especially standardised. A test suite is just as susceptible to subversion as a written standard is. If that wasn’t true then unit tests is all we’d ever need to merge a PR.
Yep, very prominently featured too. Annoying, I had to close a modal Sign in with Google popup first, which shouldn't exist since there is already a button for that. (Also, thanks for reminding me my rewards there are about to expire since they change the program to require a credit card.)
Can anyone explain to me why we couldn't just use client SSL certs everywhere? Before the first time you connect to a website, your browser asks if you want to generate a new cert or reuse an existing one, you make a choice, and from then on you interact with that site as an identity tied to that cert and you're done. From the servers point of view, the user's identity is a key fingerprint, which is just a property of the connection. Why is it more complicated than that?
Oh right, the benevolent overlords, in their wisdom, discerned that mere mortals can't be trusted with private key material.
Conceptually, this is exactly how webauthn works. Except your identity is always per-site, and the site itself stores your per-site secret, encrypted by some mechanism you control (HSM or whatever).
The centralized PKI isn't ready yet, but the day the USG is able to generate your private key for you at birth and then sign your daily driver with it for you on demand, that's the day we get client side certificate authentication.
> Before the first time you connect to a website, your browser asks if you want to generate a new cert or reuse an existing one, you make a choice
The server has to have some way of verifying your certificate. The workflow I would like to see is that the server runs its own CA that it uses to sign client certificate signing requests and then uses that CA to verify any client side certificate presented. If combined with a username and password, it would effectively be 2FA without a shared secret (outside of TLS connection negotiation).
The same benefit we get by using the external certificate authority to verify that I'm connecting to a certain website and not some fraudulent version of it.
To put it another way, the benefit I get by having my computer verify that I'm connecting to news.ycombinator.com and not some fraudulent website is so that I don't inadvertently transmit my account credentials to a scammer.
The benefit news.ycombinator.com gets by verifying a client certificate I send them is that they can verify that the user u801e is establishing a connection to them and not some scammer who happens to have my account credentials.
Those benefits are lost if either the server or client sends a self signed certificate, because there's no one who we can use to verify the authenticity of the certificate. The reason using an external CA is not needed on the server side is, in my opinion, because the server is the one who's handling the account creation, so it doesn't need an external authority other than itself to verify whether the certificate is valid. If the server just accepted a self-signed certificate, then how does it verify that the certificate is valid?
In my imagined system, there's no need for the CSR dance because hey, if the client can sign the crypto challenge and initiate a connection, then it holds the private key material associated with this certificate/account and they own it, and that's that.
My mental model is basically like SSH-ing into a box. All the client does is pin the server's public key fingerprint and moan if it changes. The only additional element is an affordance where the box would essentially allow all comers to create a user account and a corresponding `~/ssh/authorized_keys` with their pubkey in it.
In the web-app, of course it's not making unix user accounts, but it's associating the self-signed cert with a user account (how ever that might be implemented) the first time it sees a new cert. Whoever shows up with that cert in the future is automatically 'logged in' as the corresponding user account.
So, genuine question, what does it mean for the client cert to be potentially invalid? What could lead to that case in the system you're imagining? Under what cases would you either a) not grant a CSR in the first place or b) revoke a cert your CA signed?
> if the client can sign the crypto challenge and initiate a connection
How can the server verify it's the same client signing the crypto challenge with the same private key?
> what does it mean for the client cert to be potentially invalid?
The certificate's signature cannot be verified. Assume a client decides to create a certificate and send it as part of the TLS connection negotiation. The server would reject it because the signature on that certificate isn't valid since the server CA did not sign it.
> What could lead to that case in the system you're imagining?
Someone who's trying to access my account (assuming news.ycombinator.com requires a client side TLS certificate as part of the authentication process) tries to forge the client side certificate. If the certificate is self signed, how will the server know it's from me versus someone else? How do we maintain the association between a particular client and a key pair?
> Under what cases would you either a) not grant a CSR in the first place
For someone creating an account, there would be no reason to reject the CSR. For someone trying to add another device with a different key pair under the same account, not being able to show they have access to the first device would be a reason to reject it.
If we're talking about an account at a bank, a CSR could be rejected if the person is unable to establish that they're the actual account holder (through some form of out of band authentication like a bank official checking my drivers license and passport).
> or revoke a cert your CA signed?
If someone decides to delete their account, then revoking the certificate used as part of the authentication process would be the appropriate course of action.
> Someone who's trying to access my account (assuming news.ycombinator.com requires a client side TLS certificate as part of the authentication process) tries to forge the client side certificate. If the certificate is self signed, how will the server know it's from me versus someone else? How do we maintain the association between a particular client and a key pair?
I could be deeply erroneous in my understanding of X.509 but I am pretty dang sure that a self-signed cert would in fact provide that guarantee.
All certificates (self-signed or otherwise) have an associated private key. In the case of a CA-signed cert, the CA never sees the private key of the cert it's signing. So in your scenario, the server can know it's you and not someone else (assuming you kept your private key secret…) because in establishing the connection, the client signed a challenge that only the holder of the certificate's private key could correctly sign. Whether the cert is signed by a CA or self-signed doesn't change this property.
The CA-signing doesn't provide the property of unique identity—public key crypto does that already. CA-signing just provides a "chain of blessings" that gives the peers on the connection a heuristic for determining how much they should trust the identity on the other end of the line.
Yes, just like passwords need to be rotated at some point. Of course in 2023 people have already reconsidered what the practical effect on security of that policy was as opposed to the theoretical effect. Perhaps client certificate rotation would be as unnecessary as password rotation for similar reasons or perhaps automation like for server certificates could be used for similar reason.
Maybe it’s that all this stuff is still new but whenever something offers PassKey support I now add 3:
- one on android
- one on iOS
- one in 1Password
Even more fun when it’s mixed with yubikeys, add primary key and secondary key to that list
I now have a spreadsheet to write down which website has which keys added to keep track. Hopefully something like 1Password will handle that soon, but I don’t want to risk losing access to my iCloud or Google and getting locked out. Even more confusing when browsers like chrome offer to save a passkey into the browser which is synced only within that browser (I think, exception being Safari)
I stopped trusting Google Authenticator several years ago when I realized it had no syncing, backup, or even device transfer functionality whatsoever. A quick test made me realize that if anything happened to my device, I would just lose all of my 2FA keys with no way to recover them. I also then realized that if anything happened to the app (which apparently has a couple of times throughout its existence), I’d have the same problem.
I migrated to Authy because it at least has syncing and backup functionality. Sure, it’s less secure, and I should probably self-host somehow for the best security/stability assurances, but Authy seems to work pretty well for what I need it for.
As long as one keeps the original string and or qr code safe (in a separate password database), TOTP can be put in multiple devices, is backed up & will not get locked out of accounts. But also, at the same time, none of the MFA setup flows on any website tells user to keep "this" string safe. Once that string is gone, there is no way to recover it.
I have a printed sheet with all those strings and their account names in my own memorized encoded form (like rot13). Plus my main phone, my backup phone, my tablet, all of them have same app & codes (all devices have fingerprint & pattern locks).
it is now can be synced and backed up in your google account which you can tie to your real identity with your phone number and telecom company where you can have a contract... in addition, you can have a 10$ android phone that barely moves (or your old phone) sync to your google account, get the authenticator codes, battery 77%, phone has pin, and shut it down and put in in your drawer/fireproof safe... is it better to back your secrets up on paper? why do you have to see your secrets?
I was under no impression whatsoever.
I said if you hate google you have alternatives.
Google bashing is lame.
I am sure if you have a 10 dollar phone logged in to your google account at home, offline, you never lose your 2fa codes. But hey, arent they just a long key you can import anywhere via QR-code? If you do not trust or you are one of those mysterious people who lose access to the Google account (illegal activities?) then make a copy.
All I said was it is irritating this google bashing.
I would avoid anything KeePass, simply because it seems like an absolute mess of forks. How do you know which KeePass* to use? How do you know the one you pick won't be superceeded by another fork in 2 weeks? Why does the world need KeePass, KeePassX, KeePassXC, KeePassDX and KeePass 2?
The original, KeePass 2, is quite good. The prior version is only for the old database format. The nice thing about it is you can automate sync in many ways, and it has plug-ins that do lots. Every other tool uses KeePass 2 databases.
I used KeePassXC but it didn't sync like I wanted using syncthing. Other synch stories probably work better, like Dropbox.
Kee is the browser extension I use and it's pretty good. They also have a sync service you can buy, but it's free to use with KeePass 2. I liked it better than the extension that's compatible with KeePassXC.
KeePassDX is pretty great. It's working well with my setup, especially using Brave as I avoid Chrome. Incidentally, I think recent Chrome updates have complicated things for password managers on Android but alternative browsers work great. I use it with a longer timeout to lock the database than the default.
I think KeePassX is superceded by KeePassXC.
So, if you ignore most of the other forks, you don't need much analysis paralysis, and everything works well.
For iOS, it's hard to find FLOS solutions but there are paid apps that are supposed to work well to integrate with KeePass 2 databases.
Recently, I thought it had been forcefully uninstalled somehow and that I had lost everything (well, I have a backup plan, but still...). Turns out, it changed name AND logo... so I "just" couldn't find it at its usual location, and had a hard time finding it entirely.
This feels a bit like user blaming. Imagine someone getting to the office and getting annoyed at you because they changed their name, didn’t tell you, and you used the wrong name. You could have looked them up in the corporate directory, but you don’t know what their new name is and their previous name is no longer listed.
Communication was poor, mobile OS’s should probably account for this (if for nothing else to prevent major functionality pivots / spam ware) etc. parents displeasure and me losing all my mfa tokes feels like a total rug pull by google, a pattern they are known for (sure, fool me twice, shame on me - but I never expected their mfa Token app to delete all my tokens).
Fun fact: the name of the app did not include "authenticator" before the rename. Because guess what, my Android phone is not in English. So the name was the localized version of "Google Authenticator" (I think it was Google認証). Now it's "Authenticator". No "Google", and not localized, and, obviously, not at the same place while sorted with everything else. And not the same icon.
In the next version of iOS you'll be able to use a third party app to handle the Passkey flow, like how a 3rd party app can handle the password flow today. So you'll be able to remove your passkey from iCloud and use the one inside 1Password instead.
Also, I think the browser thing with Chrome is a matter of extension support; in Edge with 1Password Beta Extension, 1Password definitely takes over Passkey flows instead of using the (absolutely insanely confusing) Windows Hello UX. Just like it takes over password saving (there's an option in settings that shows password sync settings are controlled by the 1Pass extension.) So you may just need to use the Beta extension in your Chrome for now, and I think 1Password will take over from there.
Basically we're moving towards a setup where you trust your password manager to hold onto your passkeys and then the OS will allow that integration. I don't know what the status of these features are on Android.
Ah that’s good to hear! I use the 1Password beta on Chromium browsers, but obviously that’s a bit awkward when some stuff is saved in Safari, some in 1Password and some elsewhere
It’s a bit of a mess right now and even me as an IT person, I sometimes think I have a PassKey saved for something just for it to not work, either because I used the wrong device or because I didn’t actually save one and forgot.
Or once I had accepted the prompt to store the PassKey in Arc (or some other Chromium browser) which then didn’t work in another browser when I tried to login
If I get locked out, I expect the ability to reset my passkeys (stored in iCloud primarily) with an email, just like I would with a password reset. Passkeys are cryptographic primitives replacing password strings, not replacing identity. There is a difference.
The Home Depot mobile app does something similar already. Passkeys/biometrics for a persisting an iOS session, and to re-up a session, you get emailed a six digit code to your email. Why have the password?
If email as identity as insufficient for your use case, ask the user for a government credential using Stripe Identity or ID.me, or doing a token amount charge on a financial account the user has
access to (offloading the identity proofing to their bank) to bring their account back up to a higher assurance level (“IAL”) during an access reset.
I recommend recovery contacts if you’re in the Apple ecosystem. Tangentially, setup legacy contacts as well.
For this reason, I don’t really use WebAuthN as my (only) second factor – yet.
We’ll soon be able to sync these across platforms using password managers, though. Android already has an API available for them to integrate, I believe; iOS will follow in autumn.
It will fail, like all attempts to replace passwords have failed, because it doesn't address the problem that all the orhers didn't address: users don't understand it.
Users understand passwords. They even understand entering a 6-digit number that was texted to their phone. That's about it. It has to be that easy, or it will fail. If you have to start talking about public key cryptography, you're doomed.
I disagree. WebAuthen has been conflated with USB/NFC hardware keys, while that’s technically not correct, I have found plenty of non-technical people to fully “get it”. “I don’t have to have a super complicated password because this YubiKey stores an un-hackable password for me” is the sentiment I’ve heard.
Previous attempts at replacing passwords were all nonsense. They were all about replacing symmetric keys with asymmetric keys, which to anyone who doesn’t understand the difference, it makes no sense. I mean even if you understand the difference it hardly makes any difference in usability. I still have to manage my private key and secure it myself. the only usability difference is that I don’t have to transmit it, which is not even something that I do, it’s something that whatever software I’m using does.
With a hardware key, it makes intuitive sense. Sure, maybe the distinction between a TPM, Secure Enclave, Knox, Titan or a YubiKey is hard for non-technical people to understand or reason about, but luckily for WebAuthn simple external hardware keys are becoming a norm. I have seen many completely non-tech companies adopt YubiKeys which I was delighted to see .
Not sure what you're on about... If you want to prove possession of some secret you have to be the only one possessing it. That doesn't work with shared (ie symmetric) keys. Also symmetric keys are not the most used method for auth anyway. Almost anyone uses trapdoor functions for that, to avoid password leaks. Sounds like a straw man argument.
Hardware keys are all about asymmetric cryptography, and are just basically another way to store keys. You still have to manage those keys. It's just way harder, because now it's a physical thing that's much harder to backup/copy by design.
Do we? My password manager has 1031 entries. I know maybe 3 of my passwords. For the rest, the fact that it's technically a password is mostly irrelevant to me. And there are a number of things I use that are magic link logins, where the "password" is a one-time key that gets emailed to me and used immediately.
So from my perspective, the notion of "password" is wildly obsolete; most of what passes for that these days is machine-generated strings that don't know and almost never see. I'd be perfectly happy to go one step further and have a proper protocol such that BitWarden and the site talk directly, leaving me out of things.
Well yes but sometimes I still have to enter one manually. Like on a device that doesn't support password managers, like my oculus headset or Amazon fire tv.
For sure, but the fact that using a password as a password is the exceptional case is evidence to me that the paradigm is obsolete.
Another way things like linking a TV to an account happens is not with a fixed string that we in theory invent and memorize, but with a dynamically generated one-time code. For me that's obviously better than a password, in that the code will be shorter and time-limited, while the time window to misuse a password is infinite.
Am I the only one who has 10 electronic device in my house shared by 4 members and the accounts are shared in all kind of combinations among family members and devices.
I want to share passwords of some sites and not share for all sites. If I share a password, I don't want to bugged whenever they try to log in.
If you use a password manager such as 1Password (I’m sure many others support this/will support this as well), you can save the passkeys in there and allow shared access.
Most sites also support some kind of fallback method, like magic link or a password.
How will this work in all the devices? My smart TV likely doesn't support, console doesn't support it etc. Basically my point is no matter how organised I am, there will be cases where passwords are the only option.
Typically for devices like this there are off-device authentication options such as “enter the code ABCD on aka.ms/xba” or you can always fallback to magic link which still doesn’t require storing a password. Passwords won’t be going anywhere anytime soon, but it’s good to have other options in the works.
It's not about understanding, it's just that passwords require no dependencies. I don't need to carry special hardware or install special software to define a password. Even though I carry a Yubikey with me everywhere I go it's still a bit of a burden to pull it out and plug it into my phone or PC whenever I need to use it to login to something.
users, for the most part, do not understand passwords.
some of them do, but a large portion of users do not understand why they need a password, do not understand how it keeps their account secure, or do not remember any password beyond a single use. there's a high proportion of people who do a "reset my password" every single time they log in to a service, and a smaller but still significant portion who are simply unable to sign in to any service that requires a password. they need a "computer-savvy" tech person to help them, or they just don't use it. the password is not some paragon of excellent UX that we're struggling to replicate.
Users see passwords as a barrier they need to defeat to access the thing they want, and will use any means available to them to defeat that barrier, security be damned. passwords are terrible.
"but a large portion of users do not understand why they need a password".
Exactly right. My mum has an iPad, secured by a PIN. This in itself is already an annoyance, but fine. Next, several services on the device have their own authentication. Say, the Apple ID. Email. Spotify.
The thing tech people fail to understand is that many people, including my mum, are not able to conceptualize these services, they lack in tech skills but also in abstract thinking in general.
She sees the device as a single physical device. She owns it and it should stop bothering her about access. She has it in her hands, what access?
Agreed it’s partially an education problem. But it has no more inherent UX complexity than passwords, at least not on the happy paths. People are already used to having say boarding passes in their “wallet” apps, so device-specific isn’t that hard to grok. In modern countries, you also have strong authentication systems for banking and government errands etc, which are used by millions of regular people every day without issue, despite spooky public keys lurking underneath.
I worry much more about the account recovery UX and issues. If you lose your phone, how to replace it? Is that replacement path a prime target for attackers? I’d argue key distribution (issuing, rotating, revoking, multi-device) is where almost all the subtle pitfalls are.
But the happy path is irrelevant. If everything worked all the time, then it would work - the question of whether something is good is how it does when that's not the case.
Passkeys have a lot of questions in that regard. A password is simple: "keep this secret and only give it to the person it's for". You can read it, you can write it down, the rules of how it is distributed are obvious if not secure.
Passkeys on the other hand are already not being explained: "keep this secret. Then, your device will magically use it somewhere else. But actually we keep it in the secure element, Also sometimes you can't move it to other devices. Also sometimes the part we send won't work if we send it to the wrong person, or if it's intercepted..."
Of these, the part I really worry about is the synchronization one: everything about passkeys is being structured for corporate lock in. Because the ability to manage them like passwords is not front and center, it's being treated as an after thought. "We'll handle synchronization eventually or "oh, well it'll be on your other iCloud-connected devices..."
If I want to take an offline backup? If I want to write something down or print something out to cram that passkey onto another device, can I? Or is there an additional factor there which is empowering the service to decide if I'm allowed to do that?
Too strong of a statement imo. The password happy path is still a lot of friction every time you sign in, which is why everyone except banks sets their refresh cookie expiry to months or years. Not great, cookies don’t even live in the secure element. But if you torture people with typing passwords every day they won’t come back unless they have to.
> A password is simple: "keep this secret and only give it to the person it's for".
You’re missing the recovery path. That’s not obvious at all - usually a password reset through a side channel like email. In those cases, the email is your de-facto identity, and the password is like a refresh token that is stored in your brain.
Now, I’m not saying this is better with passkeys, just that there is more to password auth than meets the eye.
> Of these, the part I really worry about is the synchronization one: everything about passkeys is being structured for corporate lock in.
Me too. I think it depends a lot on the interop story. In the best future, we get something like a password manager standard, which interops with browsers and apps. Current password managers are well positioned to use passwordless auth. As a user, I could then use say Bitwarden on all my devices, and use passwordless as it comes available to more services.
But a lot of questions are still unresolved: what if I need to sign in from a public computer? Will account recovery still use email as last resort?
Do they though? Sure they can use them, but that's a far cry from understanding.
We can keep telling people to use long passwords, to use different passwords for different webpages, to stop storing them in unencrypted on their phone or desktop.
So far this has had limited success and even with a better than average understanding users usually just end complain they can't remember all that.
At which point you try to teach them how to use password vaults. Which increases the layers of indirection by 1. Which is never a good thing when you need to explain stuff.
And then you've got webauthn, which in theory solves quite a few of these problems by simply giving people two buttons 'Give me an account' and 'Log in using my account'. Unfortunately it does this by increasing the levels of indirection another time by effectively being built on top of a password vault (but not the normal kind of password vaults because that would be too easy).
If users understood passwords they would know how and why to use a password vault. If they understood password vaults they'd understand how webauthn could help eliminate passwords.
Also, most of the marketing totally fails at explaining what passkeys are to both ordinary users AND developers.
What is a passkey? Most material I've read just defines them as a "credential" that is "used as an authentication method." That's it. It's a credential. What kind? Who knows. Only when you arrive at the Apple developer page you finally learn that they are "cryptographic key pairs". And then you start digging into WebAuthn, get a throbbing headache, close your laptop, and do something else productive instead.
Have you used webauthn with a platform authenticator? When properly implemented, it's as simple as FaceId or using your fingerprint to unlock your phone. Which are both things that normal folks have mastered quite well.
The bigger issue is that you are currently locked to a device (or, in some cases to a set of devices). This makes it tedious, because:
* you have to have an account recovery mechanism beyond the scope of WebAuthn
* you have to add each device you want to login with
We'll see if these issues get resolved, but I think that the working group is, well, working on it.
Tbh the lack of sensible account recovery in the process is why I am afraid to turn it on.
What if my phone dies with all my keys?
Do I need to maintain backups on 3 devices? I assume manually to be secure. This is so much time, esp for throwaway nonsense accounts I use yearly.
What if my phone died during a trip and backups are at home in another country. How do I email someone now?
My mom forgets a password each time she has to retype it. What if she breaks her phone with all the keys and no backups.
How do I log in on a computer without usb access that is not connected to the same network as my phone with the keys? - this workflow is already broken with gmail 2FA process with approving in gmail/youtube app.
If I even reset a passkey, how to use a friends device if mine is broken currently?
Those problems are already solved, with one complication. WebAuthn is built around the concept of multiple devices so I tend to have my platform authenticator along with a couple of Yubikeys. That means I have to lose my phone, watch, laptop, and multiple tokens I don’t keep on me at the same time before I have to use a recovery code.
Platform authenticators are built around the synchronization concept so it’s easy to keep multiple devices active. Unfortunately, Apple, Google, and Microsoft have committed to but not yet enabled cross-platform sync so until later this year you’d need to register both, say, your iCloud Keychain and Google Chrome keys separately.
Because each one is implemented separately you’d need to check your synchronization service of choice but note that e.g. iCloud explicitly supports recovery when you’ve lost all of your devices permanently:
> How do I log in on a computer without usb access that is not connected to the same network as my phone with the keys? - this workflow is already broken with gmail 2FA process with approving in gmail/youtube app.
Your computer doesn’t need to be on the same network (it uses Bluetooth). This is also a contrived situation: if you work on a computer which has been locked down that much, you don’t want to use personal accounts there anyway.
There is a solution to that, however, along with every other one of these edge cases: you type in one of the one-time recovery code the service made you setup up when enrolling. Unlike the password reset email, that isn’t commonly exploited by attackers, too.
This is partly why you should have two (as well as if one breaks). If you lose both then you probably need to work on looking after your valuables better.
We still use smartcards within the company for everything. Either standard plastic for admin access, and USB dongles for regular employees which they take home.
An "Insert the dongle" popup is instantly understandable, and we never had any problem with employees learning how to use them. Windows, Linux, Macs all eat GIDS smartcards without an issue, no extra drivers needed. Works across well web access, ssh, SASL, kerberos.
And now those people want us to move to FIDO keys, which come with each new version, one more problem, and don't work with anything, but Google stack.
You can even setup your office access control on the same smartcards.
> Using WebAuthn, you're able to use a single authenticator (like a Yubikey, for example) on any site that supports the standard. This way, as a user, you don't need to have passwords
Lol indeed, they should spend some time outside. Nobody knows what a yubikey is.
Or what 2FA means, or OTP, or how this type of authentication method is device-bound unless you sync. Or how the same service approached from different devices creates different keys.
So now we'll have classic password logins, social logins, and password-less inconsistently implemented across the internet. Normies will be even more confused now.
This article is from 2020, I can definitely testify things have changed for the better.
We started Descope.com in 2022 and WebAuthN was one of the first things we implemented, it was easy to integrate with the rest of our system and it’s becoming the primary MFA option for our customers
Descope.com looks like a knock-off of Auth0 with cool words like "Drag-and-Drop Authentication" (whatever that means), geared towards developers with the oh-so-prevalent black background and terminal-green letters, but I'm not sure I see why anyone would move off of Okta or Auth0 (aren't they the same company now, anyways?) for such a seedling company
that's the beauty of webauthn!
this login process tied your device to the email address you provided, on passkeys.guru - no access/permission was granted to the website!
the only thing shared with passkeys.guru is the pubic key of your device (which was generated specifically for passkeys.guru and cannot be used to identify you or your device on other websites)
no biometrics or any other PII was shared with passkeys.guru in the process.
technically, you can use any identifier you want with passkeys, even just a dummy username - we chose to use email as it allows pairing with other authentication methods (oauth, magiclink, etc.) that are email based
Reading about it a little bit now + referencing the article - that looks like a normal web standard, not something a proprietary player should have any business dealing with. If the major browsers will already support this, why do I need a third-party plater?
Just use the latest & greatest open-source library, no?
I was one of the devs that build the Vanguard login services, though I haven't worked on it in a long time and have since left. The SMS 2FA fallback was a stupid thing that some security architects wouldn't let us get around. I pushed pretty hard on that but alas didn't have the political capital nor time.
The main risk is that you will not be insured by FDIC any longer. However, if you remember 2008, the government was very interested in ensuring that money market funds did not lose any value ("breaking the buck"). So you are comparing an absolute FDIC guarantee to clean up the pieces if anything should break versus a no-holds-barred effort to ensure that nothing breaks in the first place, but then no guarantees if it does.
Other minor things to note: (1) You will be directly exposed to interest rates, and they can and do change quickly when nothing is locked in. This is usually in your favor (no more plummeting down instantly and climbing up very very slowly...), but it's worth recognizing. (2) As money market funds are security-like, it is usually slow to move money in and out of them. Securities trades do not settle instantly in the US, and this is intentional. Again, no issue if you know this is the case. Your broker may also hide some of this latency for you, depending on what you're buying from who.
I would say the risks are approximately the same. The biggest difference is that HYSA are insured by the FDIC up to 250K. Money market funds, purchased through a brokerage, are insured by SIPC. You get 500K of coverage total, but only up to 250K of that goes to cash equivalents. On the other hand, your brokerage likely isn’t engaged in fractional reserve banking like a bank is, so maybe your money is more secure with a brokerage.
When industry creates the standards, they make it work for themselves. Everybody else in the world is on their own. Doesn't work for you? Nobody else supports it? It's really complicated? Everyone seems to implement it differently? Not their problem! They got the standard they wanted.
If it doesn't work for you, that's your fault for not being part of the standards body when this was being proposed. Or, even if you were part of the standards body, if you don't agree to whatever the giant incumbents want, they'll go implement their own thing, defeating the purpose of the standard; so you have to agree anyway
Having the keys in your PW manager of choice is worthless if your browser/OS won't play ball. Keeping all those logins locked inside Apple/Google/MS's garden is just too juicy of a 'sticky' platform lock-in to ignore. Besides, only nerds care about integration of other key storage platforms; 98% of users will just keep them in iCloud/Hello/Google, so maintaining the APIs to enable that integration will be on the chopping block of every Product Manager.
e.g. look at Google's Authenticator app. Once you add a TOTP secret, you can't get it back out. Only recently did they add the ability to sync, but only to other Android devices you own. Those keys are hidden forever, for your protection.