The thread here seems like a dumpster fire to me. Everyone here is worrying about lock-in to an open standard, so I want to clarify things.<p>WebAuthn is an open standard. It's a way for you to prove to a website that you have a specific private key. There's no lock-in, because the key is portable (unless you don't want it to be). There's no privacy issue, because the key is unique per website. There's no security issue, because it's unphishable and can be unstealable if it's in hardware.<p>If you don't like Google or Apple, use your favorite password manager. All it will have to keep is a private key per website, and you're done. No usernames or passwords. You visit a site and are automatically logged in with a browser prompt.<p>This is amazing, it's the best thing that's ever happened to authentication. It's something the end user <i>cannot</i> have stolen. Can we be a bit more excited about it?<p>EDIT: If you want to try it, I just verified that <a href="https://www.pastery.net/" rel="nofollow">https://www.pastery.net/</a> works great with Passkeys even though I haven't touched the code in a year.<p>That means that django-webauthin also works great with Passkeys, for you Django users:<p><a href="https://pypi.org/project/django-webauthin/" rel="nofollow">https://pypi.org/project/django-webauthin/</a><p>Also, the latest Firefox on Android seems to work great.
People are raising really good points here, but I do find it interesting how negatively this news is being received vs. when Apple said the same thing: <a href="https://news.ycombinator.com/item?id=31643917" rel="nofollow">https://news.ycombinator.com/item?id=31643917</a>
Passkeys sound like another way for companies like Google and Apple to lock you into their walled garden. Having each walled garden randomly generating a key for every single domain instead of using the actual domain name as part of the key is a great way to lock regular people into their respective ecosystems.
I don't use my phone to log in to anything. All my stuff is done on a computer with a password manager.<p>At no time am I even likely to rely on Google for anything this important; every other week there's a thread about Google killing off accounts for no reason. No way would any sane person allow Google access to this with their track record. And this isn't even considering my suspicion that Google only wants to "help" with this so you're locked into their services and they are better able to track your activity.
Nah.<p>For all the talk of "one app to rule them all" (which is an awful idea) this is a step closer to that.<p>For all it's faults, crypto has one thing right -- not your keys, not your stuff. I get that doing keys/passwords is hard, but the best thing in the long run is for them to stay in the hands of the user.<p>And if not, the holder of the keys needs to be someone you can easily hold accountable, i.e. either fire, or arrest, or sue if they get it wrong.
See also <a href="https://security.googleblog.com/2022/10/SecurityofPasskeysintheGooglePasswordManager.html" rel="nofollow">https://security.googleblog.com/2022/10/SecurityofPasskeysin...</a> which provides a more technical overview
Can we have this but self-hostable and open source, please? Something like Bitwarden that you can stuff onto your own device? I know there are hosted services for handling auth on the server backend, but what about the other way around?<p>I use Krypton but that's not maintained (and already broken on some websites like Github). I trust the secure storage module of my phone and I trust my computer's TPM, unlike many other Linux users; surely it should be possible to integrate with the OS somehow to make it secure, right? The last example I saw used USB over IP to inject a virtual FIDO device, which works great, but the implementation is clearly not ready for prime time.
Google's auth is getting increasingly frustrating. Recently when I logged in with TOTP 2FA, I had to also open up YouTube on another device and click approve. What's the point of 2FA if they're just going to ignore it?
> Passkeys on users’ phones and computers are backed up and synced through the cloud to prevent lockouts in the case of device loss.<p>How do you back them up locally?
Check out AuthCompanion, a passwordless login implementation for ideas. <a href="https://github.com/authcompanion/authcompanion2" rel="nofollow">https://github.com/authcompanion/authcompanion2</a>
> A passkey on a phone can also be used to sign in on a nearby device. For example, an Android user can now sign in to a passkey-enabled website using Safari on a Mac. Similarly, passkey support in Chrome means that a Chrome user, for example on Windows, can do the same using a passkey stored on their iOS device.<p>> Since passkeys are built on industry standards, this works across different platforms and browsers - including Windows, macOS and iOS, and ChromeOS, with a uniform user experience.<p>I see no mention of Linux in these examples, which tells me that users having access to their keys is not a primary concern for these implementations?
For those of you who want something like this with Firefox on Linux, the virtual-fido project might provide a decent alternative, it uses Linux's USB-over-IP support to provide a fake FIDO device, and Firefox supports FIDO devices for WebAuthn:<p><a href="https://github.com/bulwarkid/virtual-fido/" rel="nofollow">https://github.com/bulwarkid/virtual-fido/</a>
<a href="https://news.ycombinator.com/item?id=32881956" rel="nofollow">https://news.ycombinator.com/item?id=32881956</a>
I'm noticing very little discussion about the user aspect, and I say that with non-savvy users in mind. I run a mid-sized web app/community where I've been supporting such users for a long time.<p>Right now, I offer a classic login, and a few social providers. You'd think this is straightforward to support, but about 70% of support requests consists of the endless ways in which users can mess this up.<p>"Can't get in"<p>Try recover password. Email didn't come. Because they entered the wrong email. Correct email this time. No wait, think I signed up with a social account, not sure which one, have many. Login worked. Wait now it doesn't again (saved browser password did not update).<p>This is just the tip of the iceberg. This new solution, whatever merit it has, is going to be additive. It won't replace anything, it's yet another way to log in, if at all, as it depends on websites implementing it and about 90% of the web is basically not maintained.<p>So it's only adding complexity/confusion specifically to these users, which I consider to be the vast majority. In turn leading to more support headaches.
Q: how many of you will add support to Passkeys to your application? Is it worth the effort of adding yet-another-way-to-login for your users? It will be a long time before you could use it as the ONLY way to login. You will need to figure out how to enable your existing users to convert to Passkeys. Apple has a glide path for converting username password -> but not for other mechanisms.<p>I believe we in letting the user choose whatever way is best for them to login -- and to take that burden off of the developer. If you want to learn more, check out the Show HN post on Hellō I wrote this morning. <a href="https://news.ycombinator.com/item?id=33177705#33182379" rel="nofollow">https://news.ycombinator.com/item?id=33177705#33182379</a>
It's be a damned good time for someone to start building a competing Google Sync impl & server & passkey implementation into Chromium.<p>For a while this was largely built around XMPP but now the stock Google implementation is custom.<p>I'd love a refresher crash course on what's in Chrome that's not in Chromium. It's been a long time since I used Chromium but I think when I did it seemed to have a as-best-I-could-tell working Google Sync implementation.<p>It's hard to imagine a scarier project to fork. I dont think there's a lot of resources out there for DIY'iny a Chromium fork.
I wish WebAuthn would have a standardised HTTP header or TLS extension so it would be usable without JavaScript, currently every website has to implement their own login protocol in JavaScript.<p><a href="https://github.com/w3c/webauthn/issues/1255" rel="nofollow">https://github.com/w3c/webauthn/issues/1255</a>
<a href="https://github.com/w3c/webauthn/issues/1616" rel="nofollow">https://github.com/w3c/webauthn/issues/1616</a>
Here is the technical side of how passkeys work:<p><a href="https://www.imperialviolet.org/2022/09/22/passkeys.html" rel="nofollow">https://www.imperialviolet.org/2022/09/22/passkeys.html</a>
<a href="https://news.ycombinator.com/item?id=32946750" rel="nofollow">https://news.ycombinator.com/item?id=32946750</a>
Dumb question: what keeps me from spoofing the fingerprint[1] and obtaining all the passcodes at once?<p>[1] <a href="https://phys.org/news/2005-12-biometric-expert-easy-spoof-fingerprint.html" rel="nofollow">https://phys.org/news/2005-12-biometric-expert-easy-spoof-fi...</a>
Do you know if it's possible to see a list of stored passkeys in Android? I installed the Play Service beta, managed to create a passkey and sign in, but can't see the list of credentials anywhere in the UI.