The biggest issue with passkeys is that I just can't trust the companies offering them. They are locked into the platform for reasons that are ostensibly security but often indistinguishable from platform lock-in. If you make a passkey on an Apple device as far as I can tell it will never leave that device, ever, and there is no way to change this. Of course this means you can never be phished for your credentials but if Apple decides to delete your key or you want to leave your iPhone behind, what are you supposed to do?
Every time I see a long inscrutable discussion about Passkeys, I see a weird avoidance of the "something you know" part of security. Here in the US, courts and law enforcement have every right to get your username, fingerprint, retina scan, face ID, whatever. But they don't have the right to extract something from your brain. Unless I'm missing something basic (which at this point, I don't think is my fault since this whole thing appears incredibly difficult to explain), Passkeys skips past that whole thing in favor of making it a heck of a lot easier to replace "something you know" with "something you have". Which is a security nightmare.
Here's my opposing view: I love Passkeys.<p>I use Firefox as my browser and 1Password as my password manager. On my iPhone, I use 1Password + Firefox.<p>I look at <a href="https://passkeys.directory/" rel="nofollow">https://passkeys.directory/</a> every so often and switch my logins from passwords to passkeys. This has included a lot of my common logins like GitHub, Google, and Microsoft.<p>There is a lot of confusing terminology. For some reason sites will say "login with Touch ID" or "login with Windows Hello" instead of "login with Passkey".<p>Aside from that quirk, I love it. 1Password syncs my passkeys between devices. I can use them both on my laptop and my phone. It would be inconvenient if I needed to login to a shared computer e.g. at a library or friend's house, but I don't do that often enough to care (though of course some people do, which is totally valid).
I’ve avoided passkeys so far because I just don’t have a good mental model of them. All my passwords are randomly generate and stored in a password manager so I really haven’t felt the need to switch or felt constrained by my existing set up.<p>I fully understand username/email + password and remembering the pain of things like “app specific passwords” makes me worry that some tools (open source, cli, etc) might not integrate well with password less so it’s best to stay where I am until things settle out better.
I think I'm a tech guy and know my fields. I still have no real clue how passkeys work, how it is better, what it really is.<p>When your security feature is not as simple as - remember a name and a password and store it somewhere safe - it doesn't work.<p>Something about keys that are on devices. But what happens when I use a phone and a pc? How to get access then? Do I need a User/PW for the first time? Or do I need one of those keys I have to plug into the device first?
Usernameless always seemed like an optimization too far to me.<p>I think it's totally reasonable, and probably a good thing for users having to use their username at login. Especially as it reminds them what username they are using for that service.<p>I could totally see a situation where a user uses a Usernameless passkey for years to access a service and for some reason loses access to the Usernameless passkey, and then has also forgotten the username for the service, so cannot even start an account recovery process.
I've never tried to use passkeys, but determined a while ago my hard, non-negotiable, a priori requirements which would have to be met for me to be willing to use them:<p>1. I can, if I choose, have a passkey in software (no hardware enclave, no
captive key, no TPM) even if the security of that sucks:<p><pre><code> => Implication: I can backup and copy a passkey without restriction, e.g.
putting the key material in an airgapped password safe, and without that
being visible to a website.
=> Implication: Websites can't discriminate by whether I have a passkey in
software or have any part in deciding whether I get to backup, copy or
transfer a passkey.
</code></pre>
2. I can disable any attestation functionality to do my part to prevent
any online service from making it mandatory.<p>I haven't looked into this yet, so: do, or can, passkeys, or the contemporary WebAuthn implementations in Firefox or Chrome on Linux, meet my requirements?
As someone who happily uses Yubikeys, I really don't want to use a Passkey. I want to still use a username/password and the Yubikey. Not just username and Yubikey.<p>Google tries to force use of passkey now that if you enroll a Yubikey it will now be a Passkey, instead of a second factor. With no option to disable it. I have to run the Yubikey Manager tool and then disable "FIDO2", so that I can force it only be used as a 2nd factor.
> But of course, thought leaders exist, and Apple hadn't defined what a Passkey was. One of those thought leaders took to the FIDO conference stage and announced "Passkeys are resident keys", at the same time as the unleashed a passkeys dev website (I won't link to it out of principal).<p>I'm trying to follow the developments in the 2-factor-auth space and this was one thing that confused me a lot. I've read a lot of hype on Passkeys being the next big thing but it was really hard to find an actual explanation what they are and how they work. And once I found out that these are keys that are stored on the security key, I was rather disappointed, because I really like the idea of generating keys on the fly based on the domain name that I'm authenticating against. This way I can "store" an infinite number of keys. The upside of Passkeys is supposedly that you do not need to remember which username you have on a website, but I think that's a minor upside.<p>Related question: What is the official name for the (FIDO2-based?/WebAuthn-based?) technology that calculates and reconstructs keys on the fly based on the domain name of the service that I'm authenticating against? It is really difficult to learn the right terminology in the area.<p>Edit: I think I found the answer here: <a href="https://fy.blackhats.net.au/blog/2023-02-02-how-hype-will-turn-your-security-key-into-junk/#what-is-a-resident-key" rel="nofollow">https://fy.blackhats.net.au/blog/2023-02-02-how-hype-will-tu...</a><p>A key that is reconstructed on the fly is called a "non-resident credential".
> At this point I think that Passkeys will fail in the hands of the general consumer population.<p>Actually, I think it might be worse. The predators like Apple/Google have already pounced on passkeys as a consumer capture mechanism, so they'll ensure it doesn't fail.
The part I hate most about Passkeys is that it essentially killed the FIDO1/U2F ecosystem.<p>Just about every website which implemented Passkeys removed the option to use hardware tokens with "non-resident" credentials. This means you're stuck using your Yubikey as either an insecure TOTP token, or as a practically-useless Passkey.<p>We had the <i>perfect</i> 2FA method with U2F hardware tokens, why did they have to take that away?!
For folks who don't know how passkeys work at a technical level, take a look at this implementation guide: <a href="https://webauthn.guide/" rel="nofollow">https://webauthn.guide/</a><p>I don't get the passkey hate -- moving to public key challenge for authentication is a strong step forward for web security. Each browser / OS safeguards & backs up the private key (and even if that's lost, you can still reset your auth credentials using a normal "forgot password" flow).
Passkeys can't actually replace passwords, right? I will always need a username and password with a website, then can generate a passkey as a separate auth mechanism, which if I lose, I will recover by setting up again using my username and password? I don't get how we can get to a place where passkeys are all, how do you get a passkey on a new device when you only have passkey auth on some other device enabled?
Did you know that you can turn every $2 Raspberry Pi Pico clone board into a FIDO2 stick, and even make it Yubikey compatible?
<a href="https://www.picokeys.com/" rel="nofollow">https://www.picokeys.com/</a><p>Well, not as secure as a commercial key, because the Pico doesn't have encrypted storage, but still much more secure than login/password.
I still use Keepass (well MacPass) and naively "cache" what I use regularly in Keychain because I completely distrust anyone else handling the keys to my castle. Whenever I get a Passkeys notification it's an irritation as I don't actually see what the supposed benefits of this are and I'm not really interested in changing how I work. Just feels like I'm being dragged into something complex I will never be able to escape.
My biggest issue with passkey is not passkey itself, which, when it works, is great, but more the implementation of it done on most websites.<p>Use a passkey on <a href="https://www.passkeys.io" rel="nofollow">https://www.passkeys.io</a> and it works great! On google too. But use it on PayPal, it does not anymore. Who’s to blame?
The problem with passkeys, beyond the painful UX that will scare any casual users away and the fact that they are being wielded as an extreme vendor lock-in mechanism is just that the design and implementation is so over complicated with second system syndrome.<p>If you’re going to push a replacement for passwords and want it to be universal, it should be EASY to implement. Even if the backing cryptography is complex, the actual handshake / implementation shouldn’t be. TOTP as an example is insanely easy to implement. Password auth of course is as well, despite needing to know what you are doing to get it right. Both can easily be handled entirely without JS.<p>I should quite frankly be able to just <input type=“passkey-public-key”> in a standard POST form for registration and be able to call it a day. It doesn’t justify how complex it is to set up.<p>A fitting password replacement should just be as smooth and easy as ssh. I give a website a public key, I use my private key. I manage my private keys however I see fit. I don’t need a third party involved holding my private keys hostage.
I've had Apple silently delete music from Music when I had iTunes Match, and I've stayed paying for Dropbox despite wanting to use iCloud, which would be no extra cost for me, because their mechanisms for dealing with conflicts are different - Dropbox saves a version with "Name's conflicted version 2024-04-26" in the filename, whereas AFAIK iCloud silently decides what to keep and drop so you can't manually decide how to merge a conflict.<p>I too find it hard to imagine how someone can lose <i>all</i> their passkeys three times, and I guess they may be doing something funky given their profession, but I think many of these events just happen too easily in the Apple ecosystem and my trust in them managing things like that is relatively low - hence my use of 1Password instead of iCloud keychain. The Music thing in particular really stung as I never got a good handle on what was missing - I'd just occasionally come across a "this file is missing" error when I tried to play a song, and I'm left with this kind of cloud of unknowing when it comes to my Music library.
This is quite concerning, because I've recently started a project that uses webauthn-rs. I want to minimise spam on the project while I don't want to collect PII like emails for login.<p>I wonder if it means that the author will stop working on the library after their next release, and more importantly, if the UX is going to be horrible with people unable to log in and other issues they mention.<p>On a tangent, I share their discomforts about travelling to the US. The last time I was there, I felt uncomfortable being out on the streets alone. Maybe the portrayal of police brutality towards POC is a factor (for me).
I just went through the dance of logging out of all my google accounts and then logging back into them. While I was doing that, I added passkeys as a security layer.<p>Using bitwarden, it adds them in just fine. But, if you go and try to log into a Google account with Brave, it tries to use the Brave system builtin instead of the Bitwarden one. Presenting a dialog too.<p>As an end user, I don't know if it is bitwarden, brave or google screwing this up and I can't be bothered to figure it out, so it is back to just using passwords and 2FA...
I like the idea of Passkeys, but the implementation of them being exclusively tied to my super account of Apple or Google makes me very cautious. I’ve read too many stories about automated systems killing someone’s account and the resulting havoc.<p>I understand that, in principle it’s your device, and not your account, but it feels like the fingers are too deep to hand over one more thing.<p>Adjacent to this, I really liked Steve Gibson’s SQRL. I wish that had taken off.
> "<i>If you really want passkeys, put them in a password manager you control. But don't use a platform controlled passkey store</i>"<p>That is my main reason for avoiding Passkeys;<p>I will only use Passkeys, when i can export/backup them easily and store an offline backup, without depending on some Big Tech company or whatever.
(KeepassXC can export them, but not sure if it's released and fully functional in the stable build yet.)<p>What also worries me however, is that apparently if i read correctly, each server/service/website can decide/restrict "<i>which</i> password managers/apps" are allowed to be used for the Passkeys they offer...
Honestly, I think a big part of the problem is that passkeys have been tied to hardware devices and they don't have to be. A passkey is just a public key credential, and it can easily be provided by software as well as by hardware. You would still get many of the benefits (better UX, automatically secure, prevents phishing) and the overall customer experience could be a lot better. Imagine if passkeys could be saved, transferred, and imported as easily as a PDF. Instead, we get a bunch of walled gardens where Apple/Google/Microsoft/etc are trying to be the only provider you use.
I gave up on passkeys after running Google's passkey demo and getting started example. They impement session expiration client side only. I reported it, but they said it had been reported already and they didn't intend to fix it. Seems a little careless for a tool promising improved security.
I've noticed a few websites I frequent have quietly started using passkeys (or something very similar) outside of the normal channels. My bank now asks me to go through a second factor on my phone app that seems very similar to how passkeys work and Outlook has a similar login flow but with an additional 2 digit challenge code for some reason.<p>With both of these I have little sense of what is going to happen if I lose my phone or switch to a new one. So typical passkey problems.
Somewhat related: last New Year the company I work for gave us, the employees, presents. Something I assumed to be a USB disk. Couple weeks ago I had to migrate from my old personal laptop to the desktop I finally put together and needed a USB key to put an OS on the new computer.<p>I recalled I had what I thought was a spare USB key... plugged it in only to discover it wasn't a USB disk. Wasted some time trying to figure out what it was only to discover it was some form of electronic key. Not sure how exactly it works... but, of course, Linux had no drivers for it, so it couldn't even recognize the device.<p>I tried to think about any possible uses I could want from it and whether it's worth the effort of trying to find an out-of-kernel driver for it... and after some time pondering this idea, I realized I have no use for this thing. There's no scenario in which I would like to have a device to perform this function. So, bundled it with the broken pieces of my old laptop and together they went to the garbage dump.<p>Passkey would be virtually the same thing. I cannot imagine what problem does it solve, no matter how it works. Everything about this idea seems like a bad idea. So, I'm kind of happy it's a shattered dream now. Better late then never, I guess.
Bitwarden now official released passkey support on mobile app on iOS/Iphone in Version 2024.4.2.<p>If there will be a way to backup and restore between competitors, for example from bitwarden to 1password or vice versa, im fine to go with bitwarden now.
Backup and import passkeys from Bitwarden to Bitwarden already supported.<p>So please FIDO'S contributers, find away to standardize backup&restore passkeys.
The solution to most of the author's criticisms lies in not forcibly mixing Passkeys and WebAuthn-based 2FA.<p>As long as you are satisfied with passkeys being "usernameless" (i.e. discoverable), you can offer a nice login flow with a "Sign in with a passkey" button and Passkey Autofill.<p>For 2FA use cases, you should provide a second WebAuthn configuration that does not require discoverable credentials, for example, and does not necessarily require user verification.<p>This allows a user to have both fully-fledged passkeys and, for example, security keys as a second factor to secure username/password-based login.
Users can choose what they want to do (create a passkey on e.g. iCloud or add security keys as 2FA without using precious key storage resources on the hardware tokens).<p>GitHub has done a very solid implementation of that model, and we are working on adopting it to our services and it's looking very good so far.
I wanted to use Passkeys from the initial spec stage. The UX seemed far more superior (the closest I think is passwordless via email).<p>But the more I wanted to use Passkeys are more scary it got, basically the gut feeling of losing control.<p>If we could use something akin of derived, reproduceable-ish (???) Passkeys maybe then.<p>As of right now it feels wrong.
Oof, the Passkeys ecosystem is incredibly complex. Even as someone that deals with it day in and day out at $CURRENT_CO, it can be a headache.<p>As an exercise from a developer's perspective, try creating a chart of every device type (mobile, desktop etc), browser, and Passkeys platform provider (Apple, Microsoft etc). Then fill out how each behaves across each combination, it is a nightmare!<p>I'm hopeful that we'll see more cooperation across Passkey providers to align both the devx and UX to increase adoption where it makes sense. Not holding my breath too much though.
Yeah, unfortunately passkeys are confusing and the UX is generally fucking awful. I hesitate to <i>just</i> blame the tech companies for being greedy, as a result of my experience with passkeys I'm starting to wonder if maybe they've legitimately just lost the skills and knowledge necessary to actually make usable software.<p>What's most disappointing is, password managers have already solved the problem of syncing credentials securely between multiple devices across different form factors and ecosystems, and they're perfectly usable for providing software passkey support. So <i>of course</i>.. there's no standard API for them to implement it. Instead, vendors are patching the WebAuthn APIs using WebExtensions.<p>This is sabotage.
I don't trust passkeys, and yet so far, I'm not bothered by them. This is because I use them as an <i>additional</i> way to log in.<p>The other day I noticed that for some reason GitHub couldn't seem to find my Android passkey. Weird. So I logged in using my Yubikey and recreated it.<p>But this would be a lot worse if it were your <i>only</i> way of logging in. Always have multiple authentication methods for important accounts.
> Within enterprise there still is a place for attested security keys where you can control the whole experience to avoid the vendor lockin parts. It still has rough edges though.<p>Just use PKI / X.509 with hybrid smartcards for enterprise use cases. Sure, it’s “legacy” and you need an PKI expert to set it up, but it actually works and is genuinely platform-, vendor- and protocol-agnostic. FIDO is smelly poo poo in comparison.<p>Also, smartcards had usernameless for 30 years.<p>Edit: actually we’ve been here before. Remember the <keygen> tag? Platforms (browsers) could generate a key pair for you, store the private key in their key store (I think <keygen> actually supported smartcards as well), and forward the public key to the server for enrollment. The server then sent the signed certificate back. That’s pretty much exactly passkeys. This was somewhat widely used for “high security” applications at its peak, circa 2007.<p>Similar problems like passkeys caused issues, it was difficult for users to get their keys and back them up, most people were just one hard drive crash away from loosing access.
Just wanting to get rid of "passwords" means getting rid of "something i know" as an authentication factor. That should not be the goal. The issue is that the other authentication factors have real drawbacks. It's tradeoffs all around.<p>'something i have' means carrying something around and also the possibility of it being forgotten/stolen/broken/taken by authorities (legally even!) and the repercussions of that. i'm fine with this, only if i am allowed to access/export/copy/store the keys myself. I can do that with totp auth and i do. people say this "breaks" security. but the point is: i control what i own; i control me (not you).<p>'something i am' has the worst drawback. you can't change it! the other issue is you are not the unique snowflake you think you are. Also, side note of a personal experience: India has mass fingerprinted everyone, yet in trying to do some bank transactions in India the fingerprint read/auth kept failing for an acquaintance.
There is no auth panacea. There's too many different use cases, too many players involved. You cannot create one "thing" that solves all the problems for all the people. It was hubris.<p>Instead, if "the industry" wants to solve "the problem", they need to write down all the use cases. Then we can argue about how to do that, and the result will probably be a couple different things that solve a couple different groups of use cases.<p>But what will always suck is letting "the industry" dictate to us "tech peons" how that should happen. They always come up with bloated standards that are a pain in the balls. So rather than let "the industry" solve the problem, I think we need a loose confederation of open source contributors and corporate goons to meet on some forum somewhere and hash it out. Let the solutions (<i>plural</i>) come organically without a single player controlling the conversation.
I am fully invested in the Apple keychain ecosystem, I’ve got multiple Apple devices (laptops and a phone) and passkeys have been incredible. Haven’t seen any of these issues.<p>I can understand the frustration from the author’s point of view, but I live with the other side of 2FA through weak SMS every day. My users can easily be tricked into giving up their 2FA code while being social engineered, and passkeys offer me as a developer a way to give them a more secure solution that I don’t have to worry about them reading aloud to someone calling and pretending to be CS. This is a weakness in the core of 2FA via SMS, and the author seems to be just hand waving away from that. No one SIM swaps their way to compromising a passkey, and no user can share their passkey with a scammer as far as I know.
How about we stop reinventing the fricken wheel every 3 years and let users adopt something? U2F keys were pretty danged good and they were easy to explain to my 70 year old parents "This is like your front door key to your house, it's a physical key to your Google account".
I use iCloud's Passkeys extensively and have never had saved Passkeys "wiped out". I am not disputing that data loss bugs can happen, but three times for one user sounds pretty weird given the maturity of the ecosystem.<p>The most obvious explanations seem to me to be:<p>a) Apple loses data (presumably not just Passkeys, but also photos, passwords, and other highly noticeable stuff) all the time, and I've been lucky for the last ten years. Hundreds of millions of Apple users just learn to live with this.<p>b) The author is doing something weird.<p>c) This is hyperbole.<p>I'm probably picking nits, but it's like an article raising a bunch of legitimate criticisms of the internal combustion engine mentioning that the author's car has, while sitting in the parking lot, simply exploded on three separate occasions. Like, maybe?
> Apple Keychain has personally wiped out all my Passkeys on three separate occasions. There are external reports we have recieved of other users who's Keychain Passkeys have been wiped just like mine.<p>i have been using passkeys on apple since they launched it. i have also converted all of my 2fa’s to passkeys (where supported) or enabled them as password alternatives. a lot of website support passkeys nowadays. i never encountered what the author encountered and it seems like something seriously wrong happened.<p>did anyone encounter this issue? is it logged somewhere?<p>i seriously considered dropping passwords completely for future projects, but it looks like there are still issues…
I always set up two passkeys, one in iOS and one in bitwarden. I use the former on my phone (obviously) and the latter on desktop, in addition to “normal” logins with 2FA.<p>I haven’t had a single issue yet, and while I accept that it would be annoying if iOS suddenly wiped my keys, I really feel like it shouldn’t matter: ideally you shouldn’t have only one passkey to begin with, but even if you lose it, all services I use still allow “normal” logins as long as you can 2FA with a phone number or email.
> This library ended up with Kanidm being (to my knowledge) the very first OpenSource IDM to implement passwordless (now passkeys). The experience was wonderful. You went to Kanidm, typed in your username and then were prompted to type your PIN and touch your key. Simple, fast, easy.<p>> For devices like your iPhone or Android, you would do similar - just use your Touch ID and you're in.<p>The fingerprint scanner on my phone is so finicky this would've been a dealbreaker from the get-go. I regularly have to just enter my PIN because it refuses to recognize my fingerprint.
Authentication has become incredibly complicated for normal users.<p>I work in cybersecurity and need to think hard and draw diagrams to understand how modern authentication systems work (modern = something more than passwords). The implementation part is hidden from users but they only understand "password". Sometimes "fingerprint". Anything above that is really tough.<p>While Passkeys are an interesting development, it will take time before they are part of the authentication routine of standard users.
I may be mistaken in its implications, but given the 9th Circuit's decision in U.S. v. Payne this week [1], I don't know if moving all our password knowledge to biometrics is a secure idea.<p>[1] - <a href="https://arstechnica.com/tech-policy/2024/04/cops-can-force-suspect-to-unlock-phone-with-thumbprint-us-court-rules/" rel="nofollow">https://arstechnica.com/tech-policy/2024/04/cops-can-force-s...</a>
I can't help feeling this... In an adverse world software and electronic data is too ephemeral to entrust with authentication and authorization. What if we had something solid like a Yubikey, but:<p>- credit card sized<p>- completely airgapped<p>- standardized<p>- controlled by a non-profit association<p>- hard- and software open sourced<p>- built-in camera to scan data<p>- built-in display to show data<p>- configuration mode: scan human-readable configuration<p>- data is QR code or something like Base58 to copy by hand<p>- backup by supporting applications: scan and print out data<p>- browser integration by an extension using a webcam
Question for the author regarding:<p><i>within a business where we have policy around what devices may be acceptable the ability to filter devices does matter.</i><p>Is a solution to this on desktop to use GPO policy to add a mandatory "attesting" extension (that you build yourself which just verifies the device is what it says it is), and on mobile to use a webview inside an app with similar attesting info injected into the page context??
> Just like ad-blockers, I predict that Passkeys will only be used by a small subset of the technical population<p>Hmm...<p>"As of Q3 2021, 37.0% of internet users worldwide use ad blockers, according to GWI data cited by Hootsuite."
<a href="https://www.emarketer.com/insights/ad-blocking/" rel="nofollow">https://www.emarketer.com/insights/ad-blocking/</a>
"
I think passkeys can be used just like biometric authentication is used in mobile apps right now: you sign in just like you usually do (e. g. username + password + TOTP or something), then on subsequent visits you can skip that and go through passkeys instead. New device? Just sign in with a password again.
This feels overly cynical to me. The article is a bit rambly so let me try to distill the problems:<p>1. Most relying parties support resident keys only. This makes a bad user experience because users are surprised when they run out of space, and may have to wipe their device to get more.<p>2. Most authenticators do not allow you to export your keys. If a relying party only allows a single credential per account, this creates authenticator lock-in, which is a bad user experience.<p>3. Chrome is uncooperative about the Authenticator Selection Extension, and that can make a bad user experience if the relying party rejects the device attestation after enrollment.<p>Yes, these are all bad user experiences, but they don't indict the technology. It sounds to me like the relying party can mitigate all of these issues:<p>1. Support non-resident keys. Seems like it really doesn't have to be a bad user experience. Usernames are easy to remember. Just use their email address.<p>2. Support multiple keys per account. Most users will have multiple authenticators. Let them enroll several and they're not locked into any one in particular. Most users won't care about this, but for important services it's an option.<p>3. As a relying party with strict authenticator requirements, just explain those requirements on the passkey registration page. People can read. They don't have to be <i>that</i> confused when their unsupported key doesn't work.<p>I get that there's nothing users can do when the relying party creates a bad experience, but if a relying party has all the power to create a good experience, is it really worth being this gloomy about the technology?
Passkeys are pretty useless for me. At first I was somewhat hyped, but it seems that everyone just ignores them. Chrome does not support them. I set it up on mac, today I tried to login to icloud using passkey, but it just didn't work. Few websites implemented them, but overwhelming majority of websites don't.<p>So, yeah, useless technology for now. Passwords and TOTPs are the way.
Likewise frustrated by the passkey implementation but like the idea. I’ve been experimenting with passkeys leveraging SSH tunnels. You can read more about it with a demo here: <a href="https://pico.sh/tunnels" rel="nofollow">https://pico.sh/tunnels</a>
You use it because a concensus of security experts is cool with them, a normal person has no way of analyzing it properly. I see a few post regarding “I rather stick to generated passwords and have a program memorize it for them” it’s rather funny the way they rebuke new vetted tech
At TableCheck we rolled our own passkeys SP implementation primarily for our internal users, so they can access admin-level accounts without passwords.<p>Personally I love the convenience of passkeys (coupled with 1Password pw manager), however, for whatever reason it doesn’t “feel” like Passkeys <i>replace</i> passwords but rather they <i>complement</i> them. I treat Passkeys as ephemeral—it is lovely when they work, but sometimes I still need to fallback to trusty ol’ password login.
It seems like most of these gripes are due to the web app's implementation, and not passkeys themselves. It's a bit harder supporting multiple passkeys, but certainly doable. As others have said, this is just FIDO2/WebAuthn.
I use Strongbox and store my Passkeys in a Keepass File. Vendor agnostic, private syncable and locked by my passphrase.
I like them and wish more services would implement them properly.
Passkeys has a good UX and security balance. The other method would be to memorize a 20 length random password all inside your head or let grandma create a “password” so she can easily memorize it.
Tech articles have gone the way of online recipes. I had to read his grandfather's biography to understand he had a bad experience logging in with passkeys
I suppose this means OTP's would continue gaining traction as an alternative to password managers, a convenient approach but a risky single point of failure
Hm. The main criticism is you get locked into a cloud platform storing your private key(s) when using „passkeys“. This can be convenient as you can use your favorite smart phone to authenticate everywhere or even choose to rely on local TPM storage on your laptop or PC through MS Windows. This trades convenience with the risk of a vendor lock-in. But AFAIU the FIDO2 protocol you are free to use a dedicated USB key storage instead to store your private key (protected by a PIN or passphrase) on your own. This a bit less convenient but gives you peace of mind if you hate MS/ABC/Apple.
> when the room is in a country that has a list of travel advisories including "Violent crime is more common in the US than in Australia", "There is a persistent threat of mass casualty violence and terrorist attacks in the US" and "Medical costs in the US are extremely high. You may need to pay up-front for medical assistance".<p>What's wrong with these Aussie technocrats?
Good riddance. Any system that limits my options as power user I will not promote. Lots of services only let you enroll single passkey and "hardware attestation" would only make it even bigger lock-in.<p>I like passkeys as idea for stonger security, but author somehow thinks that discrimination against devices is a good idea.<p>Sorry, no. Just no. I dont want my bank or paypal require me to use iPhone in order to login to my account.
The main thing that hurts Passkeys was how the implementation was so deeply tied to letting the browser do stuff rather than making it something like TOTP where any password manager can implement it and it's usable, agnostic from the browser. Everything about Passkeys is defined around using your browser as the agent that authenticates.<p>The problem is that browsers are <i>infamous</i> for randomly losing things like localstorage, settings and saved passwords. It's way too volatile software to do authentication with besides a "stay logged in" checkmark. In both of the main desktop browsers, a corrupt profile is often only "fixable" by just nuking it and having the browser recreate it.<p>That's what killed Passkeys; people you want as early adopters (technical folks) don't use it because browsers aren't a trustworthy storage and the implementations all severely stalled in providing alternative methods that are tied to more reliable storage mechanisms. The hyper aggressive vendor lock-in is also not helping much (to the point where KeePassXC got yelled at for providing an export mechanism).
> We missed our golden chance to eliminate passwords through a desire to capture markets and promote hype.<p>Enshittification in a nutshell. The victory of greed over utility.
Yeah, good riddance.<p>I get the capitalist inclination and desire to make things easier for people (and often infantilize them) but this just ain't it.<p>There is no <i>easy</i> solution here. Security is difficult and there are no shortcuts that involve "make things easier for the general public" that don't ALSO involve "make things MUCH HARDER (either in complexity or LIABILITY for getting it wrong) for the company providing the security."
This was so obvious from the start. Whenever big tech creates "standards" now you already know it's going to be total horse shit. Look back at the old threads when passkeys launched. HN was full of fanboys thinking it's the best since sliced bread and passwords are so yesterday. Managing your passwords takes a bit of effort like everything in life where you don't want do give away control completeley to some corporate aholes. Whenever you let someone else manage your stuff you set yourself up to getting ducked.
This was foreseeable.<p>Sometimes you just know when a thing isn't practically feasible.<p><a href="https://news.ycombinator.com/item?id=36717356">https://news.ycombinator.com/item?id=36717356</a>
Passkeys are being pushed by Government and Law Enforcement because PASSWORDS WORK and frustrate them. Police access 95% of the phones they seize so they want passkeys to be the norm because once they own the phone they own EVERYTHING you secured with passkeys.<p>There is nothing wrong is passwords.<p>There is everything wrong with biometrics.<p>Wake up!