I'm super confused as to what it means to withdraw for French users if geoIP doesn't work.
So remove 9.9.9.9 BGP announcements? Unless France wants to build a great firewall... a Ligne Maginot du DNS, I don't see how this is enforceable. The internet is not Minitel...
I thought "Passkeys are a trap" was going to be about this usability nightmare. Some sites, once connected via passkey, make it all but impossible to connect in another way. Some support multiple passkeys. Some do not. Some support passkey or something else. Some do not.
The idea and protocol are pretty solid, though we're back to a "biometrics as password" problem in many device flows, but every time I'm urged by a site to convert to a passkey, I wonder "is this site the sort that would screw this up?"
I can’t adopt Passkeys if I’m not certain they’re going to work as well as my password manager and Authenticator app, which is to say 100% of the time.
When sites ask to set up passkeys, it’s usually native passkeys (especially on iOS). And figuring out how to get the flow to set up a LastPass key by default seems unusually difficult.
I also use a MacBook, windows desktop, an iPhone and iPad. I use Firefox, edge, brave across these devices.
When I say “passkeys are a trap” they are a usability trap where no one can attest with certainty that I won’t wake up in a painful situation because I decided to adopt passkeys.
It's ironic that passkeys are most usable in conjunction with a password manager that syncs them across all of a user's devices, but this is also the scenario where they have the least security benefit over traditional passwords.
I do appreciate that passkey adoption has led to wider support for hardware security tokens for sites where I actually care about increased security over password managers, however.
The specific security benefit is that there's no way for a tech-stupid person, or a tech-literate person who's short on sleep, to copy paste their password into p4ypal.com instead of PayPal.com.
Yes but if you have a password manager that's set up well you'll never be copy pasting passwords in the first place. If the password doesn't show up you know there's a problem.
The benefit of a passkey here isn't zero but it's at the minimum.
I've used a number of password managers over decades. I'm still having to copy and paste passwords from time to time due to poor/hostile website designs, needing to authenticate into a browser/app that doesn't have the plugin configured yet, bugginess on the plugin detecting the right site, etc. And in the end, if the user can copy and paste that wherever, the user will copy and paste that wherever.
Meanwhile there are other security benefits as well. With a password, that static credential is transmitted in the handshake. It can be mishandled somewhere in between, and now that entire root credential is potentially compromised. This is just impossible with a passkey. The credential never leaves the client. In some implementations, the credential never leaves a secure enclave, never even entering the client's system memory. You can't say the same for passwords, not even close.
Yeah, a lot of websites these days seem to block or mess up autofill where I actually want it: I can’t say how many websites break credit card autocomplete, TOTP code autocomplete (e.g. via Apple’s native TOTP implementation), username/password autocomplete. I can never really tell if it’s incompetence or a misguided idea of security, but it’s extremely annoying.
This would be true if websites consistently annotated inputs correctly, but they don't. So password managers are left to guess what input is the username, which is the password, etc. and they don't always get it right.
> password doesn't show up you know there's a problem
Here is your contradiction.
The normal person will just assume that some tech isn't working today again.
A key point of passkeys seems to be that it guarantees to the site owner that the user cannot be phished, without having to make assumptions on whether the user is tech-stupid.
"it guarantees to the site owner that the user cannot be phished"
Well gee how nice for the site owner.
Problem is my priorities are my absolute ability to never lose my most critical assets through some means outside my control, not the site's convenience.
It was ok to use imperfect systems back in the days when the bank and the store and even the government all had a desk a mile away you could go to in person and get anything cleared up and override all possible "usually it works like this" with your physical presense an drivers licence and birth certificate or simply 5 people who all attest they know you.
We no longer have that ultimate backup plan, so really F anyone's attempt to justify basically tricking people into doing something unwise that puts them at actually greater risk because their life is less under their own control, and doing this under the very banner of claiming to care about the users safety!
They have to be, because quite regularly password managers fail to detect properly user name or password fields, in which case you have to copy and paste by hand.
> I do appreciate that passkey adoption has led to wider support for hardware security tokens
In my experience this simply didn’t happen. Many sites support passkeys but only the native passkey stored on the current device, but not a hardware security key. Many sites don’t even allow multiple passkeys, which is frankly required if you use hardware security because you will want multiple pieces of hardware in case one is misplaced.
What's the point of a passkey that can technically be exfiltrated off a device it was created on? I thought the whole premise of passkeys is that they can't be copied, and hence can be trusted as much as the device access control. Am I missing something?
It would introduce a different usability problem to have them remain truly stuck on a device, like, locked inside a Secure Enclave. Mainly that you’d have to do the setup again for every website, on every device. Buy a new phone? Back to the Stone Age. Authenticate with a password to each site on the new device, find the “add passkey” place, and install it.
I think that is a big step down from the convenience and friction level that the native password managers get you, where you save your password once and for the rest of your life, as long as you maintain fealty to Apple/Google/Microsoft, your password will always be there in autofill.
I might not be as thorough as others on here in my password manager setup, but I don't think my password manager setup is as phishing resistant as passkeys.
Fairly frequently, I find myself searching for the password manager entry I want, and copying the username or password.
For a while, I was very consistent in trying to fix the URLs for that password manager entry, every time it happened. But when I'm on mobile, sometimes it's just a pain.
There are quite a few scenarios - I'm logging into an app, and it doesn't use a browser window for authentication, but also logs out after a few weeks, I've been redirected to Microsoft or similar for the login, but I haven't added microsoft.com as a URL for my work login, or GitHub (I could be wrong about this example), etc.
When I list them, these reasons seem like I should have solved them already. I used to try to keep my password manager tidy, but when I'm at 674 entries and it's growing faster than I'm cleaning.
I also think Passkeys are a confusing mess, and I don't mind the idea in addition to a password/TOTP option, but definitely not instead. I do like having it as an option for Google, where I have occasionally encountered a scenario where I login from overseas, and can't login despite having everything they can possibly want (username, password, backup email, etc.). I can't remember the exact details now, so I hope I'm not being uncharitable to Google's login/lockout process, but I doubt it!
> There are quite a few scenarios - I'm logging into an app, and it doesn't use a browser window for authentication, but also logs out after a few weeks, I've been redirected to Microsoft or similar for the login, but I haven't added microsoft.com as a URL for my work login, or GitHub (I could be wrong about this example), etc.
I don't exactly understand what you mean but it seems more like a problem with the auth token.
They offer advantages but it’s anyone’s guess if the sites you use them with use most of them sanely.
1. In practice everything that saves a passkey requires a biometric to unlock each time, so you SHOULD not be required to use another factor (the secret is “something you have” and the bio is “something you are.” In practice though, now every F—-ing site insists on the damn “we emailed you a code” BS.
2. Passkeys certainly don’t need to be changed every arbitrary period like some idiotic sites (or IT admins) insist for passwords.
3. If one becomes compromised, you can revoke just the one. Unlike a password.
No.
Password managers cannot prevent you from manually copying and entering a password. With passkeys, however, you don’t enter a password; instead, you receive a "challenge" generated by using your passkey public key, which you then solve using your passkey private key. The exact same principle used for SSH keys and with SSH nobody would argue to use password authentication over SSH keys.
Of course, this doesn't stop someone from stealing your private key, or from having Claude explain how to export that key from a digital wallet and enter it into a phishing site (and yes, of course there will always be people willing to go to such lengths if it’s the only way to gain access because why wouldn't they). Still, the hurdles are significantly higher than they would be with a standard password.
Ideally, you should bind your private key to a hardware security key (such as a YubiKey or Nitrokey) or to an (of course inherently malicious and absolutely despicable) TPM module, which effectively ties the key to a specific PC. In that case, neither you nor an attacker with root privileges would be able to export the key.
The fact that I can't get passkeys to work like 10% of the time makes me think they're significantly more secure. If I can't use them to access my account, an attacker definitely won't be able to /s
Can you login using a password on an untrusted PC and be sure it's still safe? And there is no lock in. You can have multiple passkeys from different providers I have Windows and Android setup for my bank. The lock in conspiracy doesn't even make sense. Who benefits. Let's just say Google tried to only allow passkeys. Why is my bank going to drop passwords and enter into passkey only relationship with Google and/or Apple. If I have that power I am not going to use a web standard anyone can implement. I would use a proprietary system that nobody else can.
I think the repeated posts and articles constantly rehashing this topic is telling. Every thread is nearly the same in terms of some people saying “here are the reasons why passkeys don’t work for me” and other people saying “you’re holding it wrong”. I don’t think many people come away with their views changed.
It breaks the traditional login paradigm. I had a hard time trying to setup a single device as my passkey manager. Now I realize that you should make one on all your devices. My bank website, I have my password and two separate passkeys. Individual sites may have an implementation issue, but in that case I use the more troublesome password workflow. I still come across password implementation issues on some sites.
I still can use my password. I use the passkeys for the convenience and extra security. If I lost all my devices I would just login with my password and add a new passkey. I would also remove any for devices that I don't control or are damaged.
I suspect even if the site were passkey only, they would have some account recovery workflow.
From my experience, passkeys work great in the Apple ecosystem. Adding a passkey for a new site on my Mac results in that passkey syncing automatically on my iPhone and iPad via iCloud.
"But what if I lose all of my Apple devices in a freak boating accident?" people often ask or something like it. Apple has a procedure for this [1].
You can contact your "recovery contact" (a trusted friend or family member) that can help authenticate you to regain access to your account, especially if you're locked out or forgot your password.
On a new device, you login to your Apple account, make sure iCloud Keychain is enabled, and all of your credentials, including your passkeys, sync to your device.
I get it—not everyone wants or uses iCloud. Apparently, you can use 3rd party password managers like 1Password, Bitwarden, etc. to backup and recover your passkeys to use elsewhere.
Here's a video of an export from 1Password to the Passwords app on an iPhone [2].
But what I don't understand is how are passkeys improving what Apple provides here. You could have just done this with passwords and had all the ecosystem benefits you outlined.
You still need a password to exist, so while the passkey won't activate the user can still leak the account's credentials.
To cover that gap, you get rid of passwords altogether, and now users lose access if the passkey fails to sync or isn't available on one of their devices (let's say a Kindle Fire tablet)
Passkeys being bound to the domain is neat, but not without tradeoffs and practical workarounds. At least that can't be the only aspect to look at when making a choice.
Sometimes the url for the login page changes or I'm logging into a different part of the site and my password manager doesn't recognize it. My university used Duo for authentication but depending on which resource you were trying to access, the subdomain might be different. How would I immediately know that I had just typed in my credentials to a misspelled domain or a hacked user account on a school web server displaying a phishing login? That last one would be even more nefarious because my browser might not even display past xyz.abc.edu/ and it would even have a valid SSL cert. Even if my password manager didn't recognize that URL and I manually typed it in, my passkey manager certainly wouldn't even attempt sending a key.
The real problem is that companies/institutions should procure one domain name, and stick with it. There's no reasons so need to be redirected through 6 domain names when signing into Microsoft, all of which look like a phishing attempt URL.
The 1password integration works great IME. When a site supports passkeys, 1password seems to offer to save the passkey, and at login time, a little popup appears from 1password asking if I want to use my passkey, and I can either enter my password, or use TouchID to unlock 1password.
I use this across iPhone, MacOS and Windows, and haven't run into any issues.
For security? If you're not using a password manager, that means you're using the same password for almost every site. Which means every site is a point of failure for every other. This means some way of generating and saving random passwords for each site (i.e. a password manager) is absolutely required for security. You are welcome to use the password manager that comes bundled with the device you paid for (apple, android), or use paid cross-platform ones like 1password (which works well), or use free cross-platform ones (in which case you might get what you paid for).
I put passkeys in both iCloud and Bitwarden. I count on having access to one or the other, or at least being able to recover access to one or the other, but it’s the same situation with my passwords generally
In fact I quite like having separate passkeys for each manager instead of one password and -maybe- separate TOTPs (usually not) shared between them
As mentioned a cross-platform password manager like Bitwarden is the way to go in this case. But yeah, the vast majority of internet users don’t use one.
So the solution to my iDevice dying is that I have to buy a new one to maintain access to my accounts and have no option to move to non-Apple hardware?
Usually you can setup an alternate 2FA like TOTP, a recovery SMS, or something else you can use to prove who you are. And then once you're into the site, wipe the current passkey and setup a new one on your current device.
But if I can use any other form of 2FA, there is no way I'm using a passkey. The only way I would ever do so is if I have no other option.
I cannot think of any innovation that has required more defensive pleading for people to use it than passkeys. When a HN article has to be titled "passkeys are not a trap", the concept has already lost.
Seeing how effortlessly 1Password supports exporting to other clients really makes me want to use 1Password more. How does it handle other fields - Apple Passwords has like 5 fixed fields while 1P has dozens and custom fields?
This sounds like an iOS problem. Bitwarden + Firefox on Linux, or Bitwarden + Android, has never been anything but smooth for me when it comes to saving or using Passkeys.
If we go for anecdotal examples that are not representative, then in my case, Bitwarden passkey use ends in an endless loop with most websites. Import and export is still a promise or "coming soon." In the case of hardware keys, two devices are needed. I was a proponent of passkeys, but big players screwed that up, like every single shared "standard".
iOS has really good support for third party Password Managers. I've seen the integration with both Strongbox and 1Password. I've heard Bitwarden supports it as well. I think it is a Lastpass problem in this specific case.
I’ve never seen an implementation where passkeys deleted my password or could lead to a situation where it was locked out. They usually just bypass the password+2fa dance when functioning, and otherwise just don’t matter if they don’t function. (Well perhaps except home depot, where it gets mad at me every time I use a password and tries to install a new copy of the same broken passkey as last time, for my convience)
If that's so then what actual security benefit is derived from it?
Of course the sites presumably will flip the switch at some dreaded point in the future where you can no longer circumvent them, but at this rate it may take a long time to reach a use by majority of users.
On XMoney I can't access the app on my desktop because it forced me to use an iOS device to set up the account, and I guess, but don't remember it mentioning, that it created a passkey on there. There is no alternate way to log in. You're just permanently locked out. I spoke to the devs, they say that's intentional.
If you need a tutorial for something that’s supposed to be as simple and transparent as a website authentication, your standard has already failed the usability test.
This isn't a standards problem, this is an "Apple, Google, and Microsoft made using your own software difficult" problem. They have an interest in making their authenticators the default, and the settings UX on all three platforms makes it unclear that their authenticator is active as well as your own "third-party" authenticator choice.
It’s difficult to disentangle one from another, when the companies with the vested financial interest in locking you in are the board members of the consortium creating the standard.
The standard doesn't dictate the UX of settings screens. That's entirely on the platforms which own the screens and I would hope that is kept out of already-huge standards like WebAuthn.
Exactly. I'm disinclined to cut Apple, Google, and MS the benefit of doubt for steering a standards committee to spec + real world usage that privileges themselves.
It's not though. Passkeys are meant to allow you to have multiple. They also don't need to replace passwords. Take my bank setup. I have a password, a windows passkey and an android passkey. I saved the time needed to setup the passkeys, the very first time I used them. The passkeys are easier to use, than my password, and more secure.
you can see in both the lastpassword and the bitwarden tutorials that the default iOS password manager can be toggled on or off, just like the other options.
you're misunderstanding: this isn't specific to passkeys, this is for changing the password manager(s) used when filling passwords, 2fa codes and passkeys.
since the person I responded to couldn't find it, I linked tutorials. it amounts to opening the Settings app, going to "General" and then "AutoFill & Passwords", so it's also not terribly difficult to find compared to other iOS settings.
you could've at least tried to understand what's being talked about before blindly complaining.
In my experience iCloud Passwords is a superior cross-platform password manager than LastPass today, so I’d recommend going in the other direction. (Source: I switched from LastPass to Passwords a couple of years ago.)
In Coders at Work, Peter Seibel quotes Jamie Zawinski as saying that certain Netscape acquirees were people for whom "cross-platform means both Windows 3.1 and Windows 95."
You might not have heard but Lastpass got hacked fairly recently. I would be careful about storing your passwords in the cloud (or at least that cloud). Keepass / KeepassDX would be safer. Sync devices with SyncThing.
Yep, any time you're asked to set up a passkey it feels like Russian Roulette with future access to that account. A year or so ago, a site I relied on started enforcing biometric passkey enrollment. Without thinking about it I logged into the site on my phone and enrolled there, but unfortunately (a) that meant it didn't get registered as an "other device" in the internal system, and (b) the site didn't work correctly on mobile devices (legacy system). So logging in on a desktop would then demand that I activate the passkey, but of course the passkey was on the phone. No way to access it, and the site didn't offer me the QR code / bluetooth method. I don't remember exactly why, but it just didn't work - probably had something to do with it not liking Firefox on Linux or something.
And to add insult to injury, it wasn't even a single factor login the way passkey advocates promise. The site still demanded a normal password to log in! It was actually 3 factor authentication; something I know (the password), something I have (the passkey), something I am (the biometric).
This wasn't some random website that didn't matter made by nobodies. It was a US government website for managing grant money.
> Yep, any time you're asked to set up a passkey it feels like Russian Roulette with future access to that account.
We rolled out passkeys a couple of years ago (I work for an auth/CIAM provider). This was before most passkeys were synced (which gives me the heebie jeebies--that's a valuable set of private keys to be shipping around).
We built passkeys to be an alternate login method, not a primary one, for that exact reason.
Supporting multiple passkeys should be a minimum requirement for every Passkey implementation. It's generally worth naming and shaming the websites that don't implement that correctly. People want backup passkeys. People want both iOS keys and Windows keys for the most convenience.
My general advice for non-technical users that seems to work pretty well is "sign up for new sites with passkeys on your phone" because most non-technical people trust the password manager ecosystem on their phone, have some amount of multi-device sync already established, and the QR code started Bluetooth LE flow on desktop/Windows PCs for sharing passkeys works easiest with phone passkeys.
(I run a tiny site that is Passkey Only for login and it's been interesting providing technical support for it. One of the biggest recurring issues at this point is nothing in the Passkey flows themselves but the fact that the Facebook in app browser does not support Passkeys for a number of presumably security reasons, plus Meta being jerks, and having to remind new users to "Open in External Browser" before signing up/logging in when posting links to the site in Facebook.)
> The idea and protocol are pretty solid, though we're back to a "biometrics as password" problem in many device flows
It's still just biometrics as "device PIN". The crucial difference remains that the biometric data never leaves your device. To support Passkeys the remote website only ever sees your Passkeys' public keys, they never see biometric data, they never have a chance to store biometric data in a database to violate PII/HIPPAA/etc standards when it inevitably leaks to "hackers" (or gets sold to the highest bidder).
> Supporting multiple passkeys should be a minimum requirement for every Passkey implementation.
To go a step further, "multiple minimum" should be like... 5+. Enough to cover several devices (Laptop, Phone, Desktop) then at least one for backup/disaster-recovery purposes, and some wiggle-room for when replacing an old device with a new one.
P.S.: Though to re-echo the cynical refrain from the prior "is a trap" other piece [0], "Yet still Netflix does not want you to share your passkeys." In other words, services like them have a (bad, unreasonable) incentive to try keep that number down.
Netflix already tries to crackdown on account reuse by policing the number and type of devices you install it on at the same time. They don't necessarily need to double down on it by policing Passkeys. But also "Netflix is a bad actor" is a threat model that has a market correction: If you can't login to your Netflix account then don't pay for your Netflix subscription.
Netflix is more incentivized to keep people paying subscriptions than they are worried about people sharing passwords or passkeys. No one "needs" Netflix, it's an entertainment service. If they are truly a bad actor with respect to Passkeys then they upset too many consumers and lose a chunk of their audience.
My takeway from “Passkeys are a trap” is that there are like four different approaches to something that everyone just calls “passkeys”, and they are not the same. For example, some are portable and some are not.
And they always ask right when logging in which is the absolute worst time to ask anything.
If I'm logging in to your app or service it's because I want to do something. Throwing up a "hey would you like to setup this complicated auth thing before you're able to do anything else?" Is annoying at best.
Then they normally follow it up with a tutorial that blocks the part of the app you need, and a full screen modal to subscribe to their newsletter, and a cookie dialog asking to let you track them, and a popup asking you to rate them on the app store, and...
Only once I've beaten away all the interruptions am I finally able to use the damn app.
> Some sites, once connected via passkey, make it all but impossible to connect in another way.
That's the issue I had with Okta a few years back. I used a password then later added a passkey through Bitwarden on my work laptop. Bitwarden hadn't yet implemented passkeys for mobile.
I went to authenticate through Okta on my work phone. It prompted me for the passkey. Since mobile passkeys didn't exist, I got stonewalled. I had to make a blood sacrifice just to get Okta to allow password access again.
This is why I don’t like passkeys. I’m surprised the “use site from multiple devices” use case isn’t more common.
Am I nuts for accessing a site from both my mobile phone as well as from the multiple computers I use?
This also gets super messy when combined with multi-site auth services like id.me where I need to use the same login to access very diverse sites and services from multiple computers (eg, irs.gov, treasurydirect.gov, disburser.treasury.gov).
I've been building latency-sensitive LLM systems for a while, and I've come to rely heavily on pre-fill-considerate mechanics like ping-pong overlapped async context construction. For interactive mechanics, the worst case, even if rare, is problematic.
Consideration of mutation rate (a sort of temporal Shannon-ish coding/ordering) lives in there (with some RoPE-friendly structuring). Note: That was a vacation project, not the day job, but similar principles apply even with larger models.
Codex is fabulous at work, where token use is near limitless and ultra-thorough tool use is welcome. Go ahead and fire off searches for look-alike terms on my 96-core cloud instance.
By contrast, Claude Code's bias to make assumptions of reasonableness about underlying systems has proven to be immensely frustrating over the last month or two, both personally and at work. I've wasted days on "that was my mistake. I've been reporting numbers on the old architecture because I hadn't enabled the new one in the config" both at work and home. It's immensely frustrating.
But here we are. Wrestling with energetic idiots in model form, wrangled by over-specific harnesses that struggle to stay off of deranged side-quests.
Arguably this is already happening: the whole state of the model gets fed through from token to token, and even just shoving a bunch of dashes in between the input tokens and the model's output can improve performance (thinking tokens from the model help a little bit more, but the difference is not as large as you mught expect).
I have heard so many of my co-workers use "load-bearing" over the last couple of months. It's truly comical. Maybe this is a way that we can make "fetch" happen.
The thing is that some people start to adopt certain "mannerisms" from their LLM of choice. It's not funny in and by itself, but it tends to be unnecessarily pompous words/expressions as well. Relevant: https://www.vice.com/en/article/youre-not-imagining-it-peopl...
I've seen this too and I get it. However, we should not assume that certain phrases are AI tells. And that was my point. There are all kinds of things I see described here as "AI slop" that are things I just do, and have done, for decades.
I've renovated houses (and I have a bad habit of buying 100 year old hacked up chaos-boxes - my current house was moved from one hill in San Francisco to another 80 years ago, so it's a puzzle box), so yes, I've been using "load-bearing" as a shorthand for decades, reduced to be less jargon-y by adopting "structurally essential" for increasingly international team composition, where English is a second or third language.
However, I've been hearing "load-bearing" at least two orders of magnitude more often over the last few months, particularly after uncorking Claude Code for the team.
I don't think it's a dead give-away of AI usage, and I don't think AI usage is a problem. I just think we can introduce phrases into common use by having them be used by common tools. So let's train the models on obscure/archaic terms and see what happens. Heck, we can just prompt it...
I made the decision to always talk to AI in English, in order to reduce the otherwise inevitable seep-in of AI terminology into my actual speaking and writing patterns. Czech and English are far apart enough that formulations like "load-bearing" don't cross the barrier easily.
I don't think it is. It's really easy to get a persistent, clever, hacky model to dial that down a bit and just come back to chat before stomping off into the woods.
If a model couldn't ever do that in the first place, it'll just get stuck.
I work in the "ZeroOne" space, working on concepts and prototypes for things that don't exist in market yet. Sometimes these models crank hard and immolate tokens while grounding themselves on expensive-to-ingest self-developed frameworks. If the results are well judged and the crank-turn latency is low, I'm okay with the cost as long as the model isn't wasting my time.
But when I want to do more boilerplate work, I turn down the model and thinking level and get more traditional about restraining action. For the really hard stuff, I reach for the models that will start a token bonfire in the back yard.
So remove 9.9.9.9 BGP announcements? Unless France wants to build a great firewall... a Ligne Maginot du DNS, I don't see how this is enforceable. The internet is not Minitel...