16 ms·
WebAuthn Is Great and It Sucks (2020)
- Nicolecrowe 3y ago[flagged]
- SoftTalker 3y agoIt 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.
- kahnclusions 3y agoAlso, 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.
- klabb3 3y agoAgreed 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.
- XorNot 3y agoBut 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?
- klabb3 3y ago> But the happy path is irrelevant. 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?
- baybal2 3y agoWe 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.
- deleted 3y ago[deleted]
- contravariant 3y ago> Users understand passwords 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.
- eddythompson80 3y agoI 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 .
- megous 3y agoNot 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.
- chrisco255 3y agoIt'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.
- wpietri 3y ago> Users understand passwords. 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.
- wkat4242 3y agoWell 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.
- wpietri 3y agoFor 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.
- YetAnotherNick 3y agoAm 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.
- jackson1442 3y agoIf 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.
- deleted 3y ago[deleted]
- notatoad 3y agousers, 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.
- dahwolf 3y ago"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?
- mooreds 3y agoHave 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.
- thealistra 3y agoTbh 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? This is all solved with a password reset email.
- acdha 3y agoThose 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: https://support.apple.com/en-us/HT213305 https://support.apple.com/en-us/HT213305 > 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.
- dumdumchan 3y agoThats not it. If it were, yubikey would be everywhere. Whats more intuitive than inserting a key to unlock your account?
- politelemon 3y agoLosing it.
- sangriafria 3y agoThis 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.
- artdigital 3y agoLittle question on that topic 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) How are you all handling that?
- lxgr 3y agoFor 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.
- aseipp 3y agoIn 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.
- artdigital 3y agoAh 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
- morpheuskafka 3y agoThis article is from April 2020, over three years ago. Since then, both Apple and Google have implemented WebAuthn for passwordless account signin. Best Buy does too. edit: eBay does too, I remembered right according to the list posted below. Some notable ones are DocuSign, PayPal, Shopify, Adobe, and CVS.
- ajkjk 3y ago... Best Buy?
- toomuchtodo 3y agoOne of the first! https://old.reddit.com/r/apple/comments/xk6hiq/bestbuycom_amongst_the_first_web_sites_to_use/ https://old.reddit.com/r/apple/comments/xk6hiq/bestbuycom_am... Tracking: https://passkeys.directory/ https://passkeys.directory/
- morpheuskafka 3y agoYep, 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.) https://imgur.com/mVfFdtc https://imgur.com/mVfFdtc https://imgur.com/ZXwB2QH https://imgur.com/ZXwB2QH
- drdaeman 3y agoAh, yes, a well-known example on how to not do it. They don't support non-biometric authenticators, so one can't use e.g. Yubikey.
- mooreds 3y agoIf you are looking for a list of sites that support webauthn, this is a decent one: https://passkeys.directory/ https://passkeys.directory/ (sponsored by 1password). Edit: oops, sibling comment mentioned this too.
- candiddevmike 3y ago
- syntaxing 3y agoDoes a bank support this yet? I just want a bank with a good HYSA and security like WebAuthn or yubikeys.
- rcme 3y agoYou’ll get a better yield with a money market fund.
- syntaxing 3y agoI’ve been debating about this, is there a risk I’m not taking into account to if I switch from HYSA to money market fund?
- rcme 3y agoI 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.
- exmadscientist 3y agoThe 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.
- briHass 3y agoI'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.
- nyolfen 3y agoauthenticator allows you to export your totp's via qr code, and the sync works for ios as well
- briHass 3y agoFair 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.
- szasamasa 3y agoso it is not a 2nd factor any more since with your master pass anybody can get any passwords and the totp codes
- 0xbadcafebee 3y agoWhen 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
- mooreds 3y ago3 years old, as other folks have noted. We (FusionAuth, my employer) implemented it last year and things have improved a lot, though there are still issues. We put together a vendor neutral site discussing all things WebAuthn here: https://webauthn.wtf/ https://webauthn.wtf/
- bvanderveen 3y agoCan 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. Nevermind, move along.
- u801e 3y ago> 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).
- bvanderveen 3y agoWhat benefit would the site operator see by running a CA and requiring clients to do that dance vs allowing self-signed certs?
- u801e 3y agoThe 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?
- mort96 3y ago> 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 Security people are literally delusional.
- dahwolf 3y agoLol 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.
- omerc 3y agoThis 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
- tomgs 3y agoDescope.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
- omerc 3y agogive https://passkeys.guru/ https://passkeys.guru/ a try and see how it works compared to what you know
- tomgs 3y agoFuck me. No permission window? Just like that, email --> scan barcode --> login? Where do I see what permissions I just granted from my (naturally, dummy) gmail account? What happens next time I want to login?
- omerc 3y agothat'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