Passkeys: A shattered dream
fy.blackhats.net.au
fy.blackhats.net.au
Ideally, you should be able to get an authenticator's public key and be able to enroll one without presenting the authenticator itself, allowing you to keep it in a safe/etc.
This would enable an easy workflow - enroll main authenticator as normal, then enroll your safely-stored backup by pasting its public key. If you lose your main, go to your safe, get your backup and "promote" it to primary and enroll a new backup one which goes in the safe.
In reality websites should not allow setting up a single passkey.
I remember AWS having some weird choices at some point too, not sure how they are currently.
But yeah, typically I think most services have had multiple choises available at the same time.
Technically, by not being copyable, a resident key isn't a "Passkey," but that's just terminology and it serves the same purpose as a passkey.
"passkey": {
"type": "webauthn",
"createdAt": 1696352105,
"privateKey": "eyJrdHkiOiJ...",
"userHandle": "cafebabeDeadBeef..."
},This comment just 4 months ago from 1Password says that exporting isn't possible: https://www.reddit.com/r/1Password/comments/18m4iph/comment/...
And I haven't seen any announcements in the opposite direction.
————
Edit: so I just checked and I can confirm that it's not possible to export passkeys from 1Password. Neither of the two available export options include passkeys.
> • 1PUX A 1Password Unencrypted Export (1pux) file will export all your data, except your passkeys. You'll need to create new passkeys with your next password manager
> • CSV (Export only certain fields) A comma-separated values file (.csv) will export only certain fields. It won't export data such as custom fields or file attachments.
To answer your question, "bamboo menu, Copy Item JSON" which I believe is turned on due to my "Preferences, Advanced, Show debugging tools" being checked. I actually did try the $(op item get --format=json $its_uuid) first but figured there was some sekrit env var or --fields some_horseshit that I needed to dig up and it was more energy than I wanted to spend for a HN comment
So, OT1H, what I send was half true - they are available for export but only after some hoop jumping and seemingly not in the official export packaging, which I suppose almost guarantees they will not "round trip" back into a Vault in any kind of disaster recovery scenario
It seems those 1Password jokers just get great thrills out of ensuring that anytime I have something to praise them for they ensure they have some user hostile stupidity ready and waiting to drive people away
$ cd ~/Library/Group Containers/2BUA8C4S2C.com.1password/Library/Application Support/1Password/Data
$ sqlite3 -readonly 1password.sqlite
sqlite> .tables
account_objects creation_drafts item_overviews ssh_pubkeys
accounts deleted_accounts item_usage users
autofill editing_drafts kanon_autofill
collection_map feature_flags objects
config item_details search_weightingThe whole fucking point of a password manager, though, is to store and securely provide authn material while ensuring users can’t lose it… which necessarily includes ability to access it, and back it up.
It looks a LOT like passkeys and FIDO are, relatively effectively, backdooring what Google got beat to death for when they attempted to add “Web Environment Integrity” to browsers.
edit: But can I? I’m already questioning how hard it’s going to be, and if it’s feasible without a lotttt of hurt.
- Apple's iCloud Keychain syncs across devices
- Apple has APIs that allow third party apps to create and offer passkeys, presented as a first-class option in Apple's authentication system. I use this to sync my passkeys between my Mac, Windows PC, and iPhone.
...as long as you always keep buying apple.
I've not had a problem registering both this and my phone on any site.
Avoiding the risks of short, weak passwords? The risks of reusing passwords across sites? The inconvenience of remembering loads of passwords? The frustration of having to type passwords manually? The risk of getting phished or typing one site's password into a different site? Remembering and typing usernames? The password manager takes care of all that for you already.
And if your objective is to have a second factor just in case your password manager gets compromised? A physical button just in case someone takes over your mouse and keyboard? Or a credential stored in a secure element that's (somewhat) protected even if you use it on a compromised machine? Putting it in a password manager (or OS keyring) removes those advantages.
Password managers should be the default authentication method, and the current hack of having it type text into a password field is both unwieldy and completely avoidable.
That's the benefit you get from passkeys that no password manager will otherwise be able to give you.
Passwords are reasonably secure since we've been using them for a long time but there is in fact a huge chain of trust required to keep them secure and links in that chain frequently break.
Passkeys use public-key authentication wherein the server only stores the public half of a keypair and the client authenticates by correctly signing a challenge sent by the server, which the server then verifies using the public key.
At no point is the private key ever sent over the network or otherwise exposed to any infrastructure or code controlled by the server.
Passwords are based on symmetric cryptography. When you log in to a site using a password you give the site your password in plain text, hopefully over an encrypted communication channel such as HTTPS so that no one between you and the site can see the password.
The site then takes that plain text password and decides if it matches the plain text password you gave them when you created the account or most recently changed your password. If the site is following good security practices they aren't actually storing a copy of the password in plain text. They will store a hash of it and compare a hash of the password you just send to see if the hashes match.
Passkeys are based on asymmetric cryptography, also known as public-key cryptography. When you set up an account at a site to use passkeys your device generates a public key and a matching private key. The site is given the public key and your device keeps the private key.
When you want to log in later the site sends your device some data, your device does a computation on that data that involves the private key and sends the result to the site. The site can recognize that whatever did that computation had access to the private key that corresponds to the public key the site has on file.
Technically the place where you store your passkeys can be hacked into, but there is no technology that protects against that. You could give a tech layman 5FA and he’ll give all 5 factors to the nice man on the phone call.
Neither can passwords if you’re using a password manager to handle them.
So again, if you’ve already got a password manager, and would put your passkeys in a password manager, what is the benefit of passkeys?
With passkeys it's literally impossible.
I'd see having the user add the domain themselves, or get the user to copy/past the password themselves on some other form. But the phishing is not happening on the password manager side, and these use cases still exist even after you chose passkeys (i.e. I'd still need to somewhat log into Google's auth from my Nest hub for instance to have it show the calendar)
In any case users are trained by the internet to need to search for the right password outside the pinned domains. Most of the time I guarantee people don't add the extra domains to the password records. So when a phishing site pops up they'll do the same: search for the site name/domain that they think they're logging into and go from there.
Password managers solve password reuse, weak passwords, etc. but IMO do not solve phishing, especially not for the kind of user who's most susceptible t it (little technical understand, hates this stuff, just wants to follow instructions and not deal with it), but passkeys might.
These issues won't be solved unless passkeys work absolutely everywhere the user has to authenticate. Logon required or weird and funky domains is currently due to service providers being a mess themselves (I'm looking at you, Microsoft). So should we expect them to miraculously get their act together and have each of these system flawlessly work with their passkey auth. from now on ?
That's where I think we're stuck with that class of issue for as long as there are multiple auth systems, passkeys or not.
I'd still recommend using a password manager, as overall and in practice the risk of phishing and (re)using (weak) passwords is far greater than this kind of rare vulnerabilities (and also I work for a company that makes a password manager ^^)
See https://lock.cmpxchg8b.com/passmgrs.html if you'd like to know more
I dunno about you. But I like being able to get my passwords out of the password manager. How is not being able to do so a feature?
A password manager, OTOH, is happy to hand out your private key ("password" in this case) to anyone that has access to it.
I want to move my passkeys where I want and use tools I want.
Not allowing anyway of changing passkeys is terrible. Imagine someone switches from IOS to android. How do they use their passkeys?
Even if they had a big “warning don’t do this” sign it would be better than not allowing it in anyway.
Who says you can't change your passkeys? Just log into the site with your existing passkey (or other 2FA) and change it.
Edit: The other great part is that the server just stores your public key, so it's idiot proof on their end. It makes a breach effectively useless, since offline cracking is impossible.
The value of these seem very low. Passkeys are a solution looking for a problem.
Mayve 10 years ago before password managers became a thing they made more sense? Now they're just kind of annoying and hard to share (sharing passwords is a real need for many people /applications / services)
This is absolutely not true, it depends heavily on usage patterns of the password manager and its features. Not all are browser extensions that autofill, and even if they did, sites change their domains for auth occasionally that break this functionality (or more often, signup is on a different domain from auth) meaning you must manually copy-paste your password somewhat often if you don't meticulously, and manually, maintain your domain list for a credential. The average person is *not* going to do that, they're going to go "huh, it broke again" and copy paste their randomly generated password.
Please, do not give security advice you are not equipped to handle.
Sure the do. All somebody needs is the password to your password manager. It's a single point of failure and by putting your passkeys in there to you've made it even more vulnerable.
Do you put a passkey on your password manager that exists outside of that ecosystem? Once you have that why not just use it for everything?
The parent wasn't giving security advice. They were asking a valid question.
Not more vulnerable than if they were just using password. You're still missing my point, password managers do not give you the ability to just copy-paste the private key of a passkey into a form field, unlike passwords. Some don't give you access to it at all (*cough* Apple *cough*). Sure you can get the private key if you have access to the password managers vault, but that's not what's being talked about. Common usage patterns matter immensely in security. At the end of the day, the attack surface for passkey-based authentication is smaller than password-based authentication, which is a step in the right direction.
> The parent wasn't giving security advice. They were asking a valid question.
The parent made a blatantly false and dangerous statement and then followed it up with a question. Did we read the same comment?
I also agree that passkey-based authentication provides a smaller attack surface than purely password-based authentication.
But putting the passkey on a second device provides an even smaller attack surface since now a bad actor needs both your device (or a MITM attack) and your password.
This is an HN forum. Nobody's giving "security advice," but I do feel like the parent comment's question hasn't been answered. Why would one store passkeys in their password manager instead of on a separate device?
I feel like we might have a mismatch in understanding what a passkey is. You make a new keypair for each account to authenticate to. A leaked passkey is generally no more vulnerable than a password when leaked.
> But putting the passkey on a second device provides an even smaller attack surface since now a bad actor needs both your device (or a MITM attack) and your password.
Correct. The gold standard is a hardware secured, non-cloud synced private key.
> This is an HN forum. Nobody's giving "security advice,"
It's a technical forum with statements on a technical topic. Making statements like that can always be misinterpreted as technical advice by default.
> but I do feel like the parent comment's question hasn't been answered. Why would one store passkeys in their password manager instead of on a separate device?
This is fair. The answer is: convenience. It is most definitely worse security posture to sync passkeys than to store them on a separate, physical device that can answer challenges without leaking the private key.
The reason to use them over passwords is they are more secure, even when synced to a cloud vault.
The big tech companies (Google, Apple, MS) have all become evil.
My understanding is the ability to do that is built directly into the spec with the attestation feature. The only thing that might slow it down is Apple choosing to not implement it and zero out their device string. Others can piggy back on that to protect themselves behind Apple's skirt, at least until Apple changes their stance anyway.
Platforms of course could just not allow Apple passkeys and only allow Apple users to use other 2FA options as well. Rest assured that small players like KeepassXC will be the first ones to have their passkeys blocked or not supported.
The whole thing is a trap IMO.
On MacOS you cannot enable passkeys (or using TouchID with them?) without enabling iCloud Keychain.
I'm fine with iCloud Keychain. But to enable it, you have to enable "autofill form password" which enables it in Safari. Disabling it in Safari disables the global setting and disables iCloud Keychain.
WTF.
Basically, the security key stores a single symmetric key. It'll generate a public/private keypair on registration, encrypt it, and send it to the server. On authentication the server will return the keypair back to the security key, which decrypts it and uses the retrieved private key for authentication.
Seeing this more and more with Chrome, like Credit Card numbers used to just save and autocomplete in browser but then they had some popup that was worded in a weird way that tricked me into saying it into Google Pay. Then I had to like type in the CCV to retrieve the card but then it also charged my bank account 1c for the privilege of autocompleting the card each time. Took me good 20 minutes to delete my card, get it saved back in the free local auto completely and shut down my Google Pay account I never knew I had.
I tried. The power-grabbing garbage was immediately apparent and sent me straight for "heck no, I'll just use passwords until they figure this out, at least that can't control my password manager".
In principle I should be very in favor of them, but the wild variety of lack of support for basics, and the built-in-the-spec ability for site X to control how I store and sync stuff is utterly bonkers. It's feeling like the OpenID promise -> OAuth platform lock-in cycle all over again, but compressed into v1.
I don’t get what the issues people have really are. I never experience them (fortunately!).
Now if we could just get the other providers that require insecure email/SMS 2FA to follow suit, that would be great...
Does it work well?
The vast majority of the population will do a worse job on the availability and security of a selfhost solution than 1Password, whose core business and value proposition is password management.
I’m a very happy user of 1Password for Families and consider it the likely the best ~$50 a year that I spend on hosted technologies.
This way you don't need to trust any single one of your friends to be 100% honest nor 100% available.
you could rsync files before you could Dropbox too, but there was still a need for a Dropbox.
I don't trust many people to do that.
I have everything encrypted and self hosted and I sometimes wonder what I would do if I was suffering from amnesia after an accident for example. And having a note somewhere telling me I have a safe in bank X is the only solution I have found.
Ah! I have the exact same recurring worry, it's very unpleasant. I'd really prefer to keep home media unencrypted, but the thought of a robber seeing my tax returns or photos of my infant daughter is constantly at the back of my mind.
Even worse is the eventuality of them getting their hand of a picture of your ID card or passport, or whatever they can later use to steal your identity. Identity theft is nightmare stuff.
Huh? There's plenty of already existing legal ways to do that. Just leave your key with your lawyer or a notary, and existing regulation about fiduciary duty handle everything just fine. You can also make normal private contracts that stipulate fiduciary duties, courts will enforce those contracts just fine.
As a technical alternative (or augmentation), you can also use a threshold secret sharing mechanism to store your keys amongst your friends and/or with companies.
Now what you can complain about is that there is no convenient way to do all of this. And that's a very legitimate complaint! Convenience is important.
However, the way to get convenience is not via regulation.
It is, because no company is ever going to give you the convenience you want at their own expense ;)
You can also write:
> The blind faith some people have in [regulation and government] despite all evidence always leaves me in awe.
In any case, markets ain't perfect. They are made of people, after all. But they are better than the alternatives. And most importantly: if you don't like what's on offer, you are allowed to get an alternative without going to jail.
The Western world and Asia is a pretty good evidence that government works. If you want the libertarian dream of no government, you can go to Somalia, or South Sudan, or Yemen, or whatever failed states you can think about.
> And most importantly: if you don't like what's on offer, you are allowed to get an alternative without going to jail.
Oh sure you won't go to jail, but the alternative doesn't exists so you can't get it either. Like the convenient safe storage we both wish it existed.
In totalitarian dictatorship, you can't build such a tool without getting murdered or jailed, in totalitarian Capitalism you can build it but it will eventually be blocked from reaching any significant room on the market because of big corps or if you raise money from VC in order to get the marketing you need, it will eventually be bought out by one of the big player who will close or enshitify it.
The good alternative is what's called democracy, where the sovereign people vote for things instead of leaving the power to the party or the market.
Would you really trust your lawyer with your bitcoin seed? If they stole everything from you, how would you even prove it?
But the whole thing depends on how much you own in bitcoin.
If it's a whole lot, check how other people in more traditional domains are dealing with their lawyers or notaries handling these sums. (For one, it's a bit easier with bitcoin, because you don't need to tell your lawyer or notary what you are giving them. And you can encrypt the private key data with something derived from an easy to remember password. It doesn't need to be 100% cryptograhpically secure, it just needs to lower the temptation for your lawyer.)
Btw, I think the bigger problem in practice wouldn't be your lawyer stealing from you, but your lawyer somehow losing your data.
Fun fact: the reason why giving it to your lawyer or a notary works is exactly because of regulation regarding these professions. Without regulations, there would be no such alternative.
Whether or not you can import them into something else though…
Such things do have purposes, in high-stakes environments. They prevent accidents. The vast majority of uses on the public web are not even remotely in that realm. It'd be better off being a separate spec that only a handful of internal-only systems use, ideally requiring MDM to set up conveniently (to strongly discourage normal and even high-stakes-normal website usage).
My banking website has absolutely no business knowing and being able to approve or deny what brand my authenticator is.
[1] https://keepassxc.org/docs/KeePassXC_UserGuide#_passkeys
They used to offer their apps offline and you could "host" it anywhere. Venture Capital ruined them.
1Password has fallen hard from their earlier excellence.
BitWarden is open source to a large degree and even provides an (open source) server for self-hosting.
Google loves that nonsense, don't they? It's as though they think so highly of themselves that they cannot imagine they might not be strictly doing us all a favor by signing us up for their services.
Fifteen years later, I still have friends occasionally sending messages to a GMail address I never asked for, never used, and didn't even know about for most of a year while it was virally spreading through people's address books, silently diverting mail away from my actual address. The only time I used this account, after I discovered that it existed, was to delete it - but GMail apparently still suggests it when people type my name, because I get an "oops, sent this to the wrong address" forward every few months.
No I will not be knowingly using any Google passkey service, but perhaps I will someday find that they have signed me up for it anyway.
Now you have lots of chaff / ablative / imposter emails to divert away all the robo-mailers, spear fishers, destitute princes, and the like. Even the tiniest little mistake and the email goes to one of a million diversion accounts.
Side Not-a-joke: On this topic, I also really hate two-factor authentication you don't sign up for, don't want, yet are forced to add to your account, because Google Play is too much of SCIF to just let you log in. Even more security theater for the most basic activities. Now I need two-factor every time I try to use GitHub. Ugg.
I had my Facebook taken over because I had all notifications disabled and forgot that the email address was associated to it. Some criminal behind an Egyptian IP address took my old email and was in my Facebook within two days of me surrendering it.
The dark pattern about signing up for google pay is absolutely inexcusable though. Sorry you're going through that.
I believe those transactions are never confirmed and are reverted after 7 days or something like that
That's not true. Passkeys actually require iCloud Keychain, which is obnoxious, because you can't use the OS passkey support without using iCloud. And you can't even manually export passkeys from iCloud Keychain, which is totally opaque.
So it is still platform lock-in, just not in the way you described.
There are choices.
It doesn't matter how many SaaSes offer it or how many brands of devices adopt it. It still means that for access to all of your accounts, you either 1. Have to stay with that brand of device or 2. Have to rely on the goodwill of the SaaS not to suddenly start raising their prices (the comparison here is passwords, which are free).
Before you say that switching providers is possible, that doesn't really matter. Let's say I stored the passkeys on my iPhone/iCloud. And then it got stolen.. whoops! Now I must at the very least acquire another Apple device until I can reach any of my accounts, i.e. I'm tech-dead until I do so.
If switching is not frictionless, it's an absurd level of lock-in, almost making it impossible. I have to go into every single account and add a new passkey? What if I forget one when I switch, then I'm out of luck and can never use the account again?
I feel bad for the author. They put a lot of their heart into something that could have been awesome.
Maybe they sorted all this out so it “just works”, but there seems to be so many potential pitfalls, that I feel like I’d need to spend weeks researching stuff and testing edge cases before I could feel safe using it. No one is going to do that.
With a password, I know it works now, and it will work in 40 years. I don’t have that same kind of confidence with a passkey. Even if it’s great, if people don’t adopt it in mass, it will fade away and be removed, so how deep do I want to go? This isn’t something I want to be an early adopter on, at least not for anything I care about.
FWIW I don't think that this makes passwords redundant in general, but with passkeys, password becomes a last-ditch safety valve to regain access to the account. Meaning that it can be generated, very long, and stored in a way that is optimized for safety and security over ease of access (like, say, an encrypted text file on multiple USB sticks stored in different physical locations).
The problem though is that you have to do this for every single site you access. So if you have 100 log ins and are switching PC or phone, you'll have to do this same dance 100 times in the next period. And of course, if you're switching because you lost your one device that was registered this way...
"Communicate over bluetooth" doesn't mean anything. What app or BT device would they be using? How would a PC communicate with a YubiKey over bluetooth?
I have no idea where you got this strange concept from, but registering multiple passkeys from multiple devices on the same account on a site requires no communication between the devices - it only requires a trusted device to approve the request.
No idea how Yubikey works, never used it.
Because surely such devices never get stolen, or dropped from a cliff.
What's supposed to happen is when you tell the site you want to use a passkey and one is not available to your Linux desktop's browser you are shown a QR code that you can scan on your phone. The login will then take place via the phone using your passkey that is on the phone for that site.
If you want to test to see if your browser handles this right you can do so at <https://www.passkeys.io/>.
Once you are logged in with your passkey from you phone you should be able to go to your account settings on the site and somewhere in there find an option to add another passkey. You can then add a passkey generated by your Linux browser or your Linux password manager if you use a password manager that supports passkeys.
Some will object that this is not good enough because they might want to login to some desktop they have never logged in from before when they do not have their phone handy.
That's probably not as big a problem as they expect though because unless you are using passwords you have memorized the same problem applies to passwords. I've got over 400 accounts in my password manager, almost all with long random unique passwords. That means I'm not going to be logging in somewhere new to any of those sites unless I've got access to my password manager, which in practice means unless I've got my phone or tablet with me.
Once on vacation I shattered my phone. Only time that’s ever happened and I happens to be away from home. I was able to get a new phone at the local Apple Store, but the only reason I was able to get setup and running again was I happened to bring my iPad, by sheer dumb luck. Other than using it for 2FA to get my new phone setup, I didn’t use it at all.
In my most recent trip I brought my recovery key with me, and know my password for that 1 account. As long as I can get into that, I can get everything else setup from there. But I need someplace to start to make myself whole again. It seems like PassKeys make that more risky.
There’s some hope for interoperability between password managers someday. There doesn’t seem to be agreement on how you can securely export, transfer and import today however.
- you can log into your 1password on multiple devices
- you can sign in by QR code, with the help of whichever phone has the passkey on it
- you can add multiple per-device passkeys to your accounts of interest (for example, log into github on desktop and then add a passkey for your desktop device for that github)
- you can keep all your passkeys on a hardware dongle
- you can set up and keep all your passkeys inside an open-source manager (e.g. KeePassXC)
For first-party systems, passkeys are supposed to be stored in hardware storage (TPM chips, secure enclave, etc). Once it's in the chip, the secret key's never coming out of those pins again (unless you're a nation state with a tunneling electron microscope and a very steady hand).
(The huge exception is iCloud Keychain and whatever Google's doing for passkey sync, but that's importing from account data into hardware storage, not exporting existing credentials from a user's existing device)
Additionally, passkeys are just a synced-via-cloud implementation of FIDO2, an open standard that has other implementations you may feel more comfortable using.
For someone who requires being able to sign in to, say, GitHub from multiple different operating systems or platforms, you have a few options.
1. Use a passkey on your primary device, say an iPhone. You can still sign in to GitHub on a Windows computer or Android phone but you must have your iPhone with you. During sign in, there is an option to show a QR code on the Windows/Android, which you will point your iPhone at, and the two devices will do a secure handshake to sign you in. This is probably the worst option from a UX standpoint if you sign in on lots of devices that are not your primary.
2. Use a physical security key to store a FIDO2 key instead of a passkey. These devices are inherently cross-platform. Remember, a passkey is just a type of FIDO2 key. No one is forcing you to store it in the cloud. You can buy something like the YubiKey 5C NFC to store your keys completely offline and under your own control. The tradeoff is you will need to have it with you and you will need to plug it in every time you create an account or sign in.
3. Add multiple passkeys to your GitHub account, one for each platform you want to be able to sign in on. Unlike passwords, where an account generally only has one password at a time, it’s normal and even recommended to have at least one backup FIDO2/passkey registered with an account.
And of course these aren’t mutually exclusive, you can mix and match these techniques, perhaps depending on how important the account is or how/where you typically access it. Maybe you only use a single passkey on your primary device for your bedtime social media scrolling, but use a passkey with a backup FIDO2 security key on GitHub.
But I do agree with the point that Passkeys make it really easy to get locked in unless you’re careful.
But then I have the analogous problem of never being able to switch password managers!
The idea isn't to move your keys around willy nilly the idea is that should you need to, you're not beholden to bitwarden inc.
1. Login with the passkey from your iPhone.
2. In your account, add a new passkey from your new Android. Now both passkeys are active.
3. Login with your new Android passkey.
4. In your account, deactivate the passkey that is stored on your iPhone.
Passkeys aren’t passwords. You can have more than one active at the same time. So instead of moving a single passkey around, you add or remove them to change devices or service providers.
There’s no way I’m doing that for each of them (or figuring out which ones support passkeys).
I have so many keys scattered everywhere that I would need an excel sheet to keep track of them. I regret not doing that already .. or perhaps I regret using passkeys at all. I am still trying to figure that out.
Check whether your Yubikey supports resident keys (aka discoverable credentials) and whether the FIDO key for your account was created with residentKey: true, otherwise it’s a completely different (older) flow under the hood, where the private key actually gets sent to the server, and it wouldn’t surprise me if that’s the underlying cause of what’s happening to you.
If you read adtech docs, authenticated user sessions are the gold standard on enumerating user preferences for the sake of ads.
Un/pw friction is noted as a difficulty in achieving this. Cookies developed the way they did in response, +/- details.
If cookies go, then passkeys look a lot like a tangible and realistic solution to enumerating users via authn/z’d sessions, minus the friction of un/pw and a pw manager.
IMO, the impacts of passkeys will feed right into this solution, and while I’m not sure if you can safely argue passkeys are a nefarious plan to replace cookie tracking, I don’t think you can get a tech giant to support such a reimagining of user experience if it didn’t have ancillary benefits beyond solely security use cases. When has a company like Apple or Google ever done such an equivalently large amount of work solely in support of security?
If the website is momentarily down how are you going to access it with a password at that moment? You'd have to wait until it came back up. And then you could just as well set up the passkey.
You create one on your iPhone and another "backup" key from a desktop PC running some open source software. If your iPhone breaks you can always use the other.
Similar to a server configured to accept multiple different SSH keys.
Your passkeys sync in iCloud they aren’t device bound, just platform bound. Passkey export import is being worked on.
As I understand it the workflow would be: * get a new passkey * enroll the new passkey with all existing services * unenroll the old passkey with all existing services
That is certainly onerous for the "can my mom do this?" test. Like, I'm not even sure I want to deal with this myself and I have a Solo key (in a box).
Further, seems any service I'd want to protect with a passkey, is also a service that would be very difficult to lose access to, should I lose the passkey (or it fails). Therefore I need to enroll two passkeys with each service, to have one as a backup.
Uhh, OK. So now if I were to change passkey vendors/services - it's enroll two replacements, unenroll two? I haven't ever done this so maybe it's not as onerous as it sounds?
Most folks store passwords in password managers and don't use their brains to retrieve them.
In my experience, that’s a notebook or piece of scrap paper next to the PC with all their usernames and passwords scribbled on it.
That being said, all of the friends and extended family members that I have helped with computer issues have chosen to save several passwords in their browser’s autofill. Yet, none of them knew that they could view and edit these passwords.
But in general I haven't felt these are secure enough for the reason you say.
While my practical threat model today would make passkeys seem great, the theoretical future threat model in my head does not support it.
So the only real risk is key extraction, hardware key extraction is always possible but likely incredibly expensive, so for most threat models it is not an issue. (Software key extraction or side channels is a different problem which may be easier but in theory is not possible.)
- a PIN is hard to memorize, so people are more likely to use personally-relevant or common numbers, whereas a password can be easily be both complex and memorable - it's easy to burn through even 10 login attempts through any combination of temporary/permanent disability, stress, being drunk, damaged device... - a wipe-after-failed-attempts system is trivial to abuse, be it by a prankster or a real adversary - it's much easier to see someone's PIN over their shoulder or film them entering it
(This does depend on the specific key/protocol.)
The whole point of a passkey is that it’s something you have, not know:
- you can’t guess it because it’s a really long encryption key
- you can’t phish it because using a passkey does not give the passkey to the site, it just proves that you have the key (typical priv/pub key auth)
- you can’t steal it because passkeys are meant to never be moved from the device — it’s supposed to be impossible to extract them, as they’re supposed to live on a secure enclave type chip that is impossible to extract from
So, no, not like a password manager
sure they do if, unless you want to be held in contempt of court for not providing the information.
In practice, juries will take a refusal to divulge a password as evidence of guilt, the cops will use it as an excuse for even greater brutality, the FBI is perfectly willing to hold you without trial for years on end, and in most cases they don't need it anyway because everything lives on someone else's computer and they're perfectly willing to hand your data over if they haven't already. Furthermore, because the defense is founded on the principle that the password serves as evidence that you owned the encrypted data, if the prosecution is able to prove that you owned the encrypted data in any other way, that protection goes away.
> In Boucher, production of the unencrypted
> drive was deemed not to be a self-incriminating
> act, as the government already had
> sufficient evidence to tie the encrypted
> data to the defendant
You can certainly be compelled in a black site torture den, but most people don't have that as a looming threat yet.
Multiple people have been held in contempt for refusing to provide an encryption password by US courts.
The State of Utah instructed the jury in State vs. Valdez to infer that a suspect was guilty because he refused to provide his password to the police. On appeal, the Utah Supreme Court ruled that he had the right to withhold his password according to the 5th Amendment, and he shouldn't face negative consequences for doing so. The state appealed that ruling to the U.S. Supreme Court, citing various other state and Federal courts which have made conflicting rulings on this same issue.
Sixteen states (Indiana, Alabama, Alaska, Delaware, Iowa, Kansas, Louisiana, Maine, Michigan, Mississippi, Nebraska, North Dakota, Ohio, Oregon, South Carolina, South Dakota, and Texas) just filed a motion asking the Court to hear the case: https://www.supremecourt.gov/DocketPDF/23/23-1020/307804/202...
Quoting that brief:
"[C]ourts have issued orders requiring persons to unlock devices or provide passcodes. But courts across the country are divided as to whether the Fifth Amendment bars such orders. [...] The Court should grant certiorari to provide guidance on how the Fifth Amendment’s guarantee against self-incrimination applies in the modern context of electronic devices."
The Court has yet to decide if they'll hear arguments: https://www.supremecourt.gov/search.aspx?filename=/docket/do...
More info/commentary here: https://reason.com/volokh/2023/12/14/is-compelled-decryption... (But I recommend going directly to the primary source material—legal documents in Supreme Court cases are very accessible, even to non-lawyers.)
I use Firefox as my browser and 1Password as my password manager. On my iPhone, I use 1Password + Firefox.
I look at https://passkeys.directory/ 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.
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".
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).
- PayPal only allows one passkey and don't support logging in with it on Firefox on Windows. You still have to use your password.
- Twitter only offers it if you pay for a subscription.
- Playstation Network doesn't implement usernameless, and still asks for your email to log you in with a passkey.
It seems like we still have some way to go before we figure it all out.
You're 100% right, though I'm actually surprised that so many sites already support passkeys.
If passkeys is a good idea and consumers use them, then gradually sites will shift over. Changing how everyone in the world does auth is not going to happen overnight, or even in a year.
I don't think we should consider passkeys failed already. The widespread rollout just got started, and the ecosystem hasn't had a chance to catch up. Give it some time, and see if things get better.
Additionally, it makes 2FA quite a bit more convenient.
Lastly it's the only way to login to my Georgia Tech account without opening an app on my phone which is absurdly annoying.
I can believe it's easy. But just knowing this doesn't give you any understanding of potential downsides.
Years ago I lost access to various stack-exchange accounts when Yahoo stopped offering Oauth services. Thankfully not a biggie for me but it soured me on relying on third parties for access to a given account.
Ok, I'll bite. Anyone knows how this would be done in that setup?
"Can't" is a deal breaker, so is "use the password you had to generate and store in your manager anyway".
If you _had_ to you your passkey you'd probably have to install 1Password + the extension in your browser. This is definitely not a great workaround.
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.
The physical device can be password protected. So you have two step authentication: 1. your physical device 2. your password to that device
Phones are currently being promoted for various reasons, but I believe something like Yubikeys or other FIDO2 fobs will be a better device. You can have multiple of them, you can store one of them in your bank safe. Someone stealing it of you is proper theft which can be traced in a usual manner by police. Stealing is not enough because you still need the password. The difficulty of asking you for password remains equal to difficulty of hitting you with a wrench. You don't need to remember stuff anymore, because you can just use your physical keys. You will need to travel with those keys, but its just same as your house keys. It is probably an extra key in your key fob.
To add to it, the U2F/FIDO2 standard will make it vendor independent, and so no lock-in.
So my problem is that I keep forgetting which device, browser or app I used when I created a particular passkey. I'm never asked where I want to store a particular passkey and where I want it to be available. This is all an implicit function of a combination of factors apparently.
It's like misplacing my keys has been taken to a whole new level of abstraction :-)
Personally I only use devices that don't sync and can't be copied for security reasons.
> Stealing is not enough because you still need the password.
But then:
> You don't need to remember stuff anymore, because you can just use your physical keys.
How are these statements both true?
https://developer.mozilla.org/en-US/docs/Web/API/Web_Authent...
I haven't been into passkeys as you see, but some easy login like that leaves me with a lot of questions.
- Backups: It depends. It seems like the big players (Google, Apple) are pushing an implementation where your passkeys are backed up either in the Google Password Manager or iCloud keychain. That way if you lose your device, you can recover your passkeys the same way you recover your other phone data.
- Storage: It depends. Google and Apple are pushing phone implementations where passkeys are protected by a hardware security module of some sort, either the iOS keychain or Android Keystore. The private keys can't actually be stored in the HSM though, because you need to be able to back them up. So the passkeys are stored encrypted on disk, and the decryption key is stored in the keychain/keystore. Other options include passkeys actually stored in hardware (eg. Yubikeys, but then you can't back them up) or 3rd party password managers.
- Login: It's pretty seamless, just click "login with passkey". The browser handles finding the right passkey, and part of the signed challenge includes the domain the passkey is for, preventing MITM-style attacks. There's also a whole separate thing for authenticating a session on a different device via scanning a QR code or Bluetooth.
Here's a good fairly high-level breakdown of how it all works, if you want some additional detail: https://webauthn.wtf/how-it-works/authentication
As the article stated: "I want you to remember this quote and it's implications. Users should be able to use any device they choose without penalty."
As you've pointed out:
>> Backups: It depends. It seems like the big players (Google, Apple) are pushing an implementation where your passkeys are backed up either in the Google Password Manager or iCloud keychain. That way if you lose your device, you can recover your passkeys the same way you recover your other phone data.
and again:
>> Storage: It depends. Google and Apple are pushing phone implementations where passkeys are protected by a hardware security module of some sort, either the iOS keychain or Android Keystore. The private keys can't actually be stored in the HSM though, because you need to be able to back them up.
How can I get my passkeys and back them up on my own storage media? (e.g. USB drive, encrypted cloud storage, burn to a disc, etc.)
How can I import passkeys generated elsewhere?
If you cannot backup or import the passkeys, then you do not control them. They are not your passkeys--they belong to Google or Apple, etc.
And as the article states, in most cases these passkey providers do a piss poor job of managing their passkeys that they claim belong to you.
It's probably possible to extract passkeys from a rooted Android device, but it would definitely be out of the grasp of 99% of users. I have not looked into it in detail, but I'd expect a Frida script hooking the keystore decryption function would get the raw data, then it would be a question of interpreting whatever proprietary format Google is using for their password manager.
Besides, give the Silicon Valley venture capitalists and Harvard MBA bros a whiff of the possibility of full control over something as important as your primary authentication material and before you can whisper Richard Stallman they're out having a happy Bacchanalia toasting the name of Portunus [1], whom I will now resurrect out of our ancient past to name him the God of Platform Lockin, and us users aren't going to get a word in edgewise over the debauchery and slides projecting Total Addressable Markets.
Fortunately it seems they all got a little too drunk with power this time, but honestly it's only a matter of time before they arrange another Portunus summoning lock-in party again. This target is irresistible and the annoyance people have with passwords is too good an angle to pass up.
[1]: https://en.wikipedia.org/wiki/Portunus_(mythology) And yes, I am aware of the stream-crossing between Bacchus and another god here. But who knows what a Portunalia even is any more?
A "corporation of one" is still just me, so I'm not talking about trying to technically hack around things by pretending to be a corporation.
When you see it this way it becomes really clear that Google, as a corporation, is an absolutely atrociously awful company to be the ones holding the keys to my identity. But there aren't any good, big, easy, safe options. I need to be able to self-service. Or we need to create much smaller, more local (in some sense, not necessarily geographical) holders of the auth material that I can convince I am me and they can reset it if something goes wrong. But that gets into a complicated web-of-trust and that's never worked out.
Every actual HSM I've ever used allows some sort of encrypted export. But actual HSMs are expensive and PKCS#11 is a terrible API so they suck to use.
To note: the key to start a car is provided with the car with no specific operation, is locked to no other device, doesn't care about who's handling it, can be duplicated and passed around. It would be closer to the traditional password system in all of its aspects IMHO.
See this and let me know if it makes more sense.
To me the best explanation was just to go to the passkeys.io site, the subject is complicated enough that analogies tend to introduce a lot of cognitive noise IMHO.
The basic logic here is pretty clear imo. Passwords are still symmetric factors, and they're also completely unstandardized. So you still have to do a significant amount of manual management crap that should not exist, deal with UI that should not exist, and you still have to do some stuff if the other side (service provider) gets hacked. If we used bog standard pub/priv keys instead, then everything could become universally better. There'd be no need to worry about password policies, whether there is a character limit or not, how well and consistently individuals handle it, or anything like that ever again. Nor care if a site is breached, literally no action required because the site would only have the public key, they could publish it in clear text and it still wouldn't help attackers authenticate a single iota. Plus things like phishing and so on go away, because same thing, if the user has their agent browser to a malicious link or the like, and then it presents their pubkey, it still wouldn't do anything and the agent can't be fooled by similar looking to humans domains or anything. The agent would expect the service to present the proper signed request and anything else wouldn't work. Conceptually everything could be automated and standard without any sort of silo, all software could speak the same standard simple key format and everyone could back that up and sync it any way they wanted.
Unfortunately as is so often the case these days there's a lot of perverse incentives and players who can't resist the urge to try to add extra functionality in on top rather then just going for the low hanging fruit in a solid way first. So we've seen a confusing muddle, of existing players with financial interests who make money by helping lower the pain of the garbage that is password based mutal auth, those who see new chances to try to silo, those who want to shove in attestation and differences in password backing for good and bad reasons, mixing in concepts of hardware backing that are unnecessary, etc. I'm still hopeful something will come out of it in the end but it's been a real bummer to see how it's played out.
I think I really need to implement it myself at least once to really grasp it. Maybe that’s stupid/slow of me but that’s how I learn best.
1) In the first case what will prevent different services to track users by comparing public key... and if so I would be more at ease with a site specific randomly generated password
2) In the second case when one service is breached you'd still have to manage rotation of public key somehow, how trivially is that done with current implementation ?
To rotate, you go to the key management page of the service and delete/add a new key.
Why would you need to rotate your keys? If they're storing passwords/hashes it makes sense to rotate because they might be able to brute force the hashes on a GPU cluster, but you're not going to be able to brute force a randomly generated public key.
That sounds like a totally separate threat compared to "when one service is breached". In your last comment you were talking about your password manager being hacked, but in the post before that you were talking about the service (ie. the website you're using) being hacked?
Also, while I do agree that if your your password manager database were hacked you would need to rotate both passwords and passkeys, but I would hope that occurs far less frequently than some random service you use getting hacked.
OK, so the simplest way to understand is to first know about the previous generation.
U2F keys are designed to be used alongside a username and password, as a more secure replacement for phone apps showing 6-digit codes.
In U2F the key has a hardware 'secure element' where secrets can't be extracted, even if you plug it into a compromised machine. You get a separate public/private key pair for every account and website (so it can't be used to track you between websites) and that key pair can be used to authenticate with the website. A physical button has to be pressed to authenticate, keeping it secure even if an attacker has control over your keyboard and mouse. The browser integration takes care of letting the USB key know which website is asking to authenticate. U2F keys have to be used alongside a username and password.
For a variety of reasons U2F keys never really took off. Partly cost, partly the 'what if I lose it' issue, partly lack of uptake by websites, partly difficulty using them on mobile, partly competition from 'log in with google' type systems.
So the trade group behind U2F said "Hey, maybe we could just emulate the hardware secure element in the smartphone's OS? And while we're at it, we could save the username, and use fingerprint/faceid instead of a password, eliminate that tedious button press, and automatically back up the public/private keypairs to the cloud". They kept a USB option about for the sake of tradition, but it's on life support.
So that's the mental model of a Passkey: It's like an impossible-to-clone USB hardware secure element that does challenge-response authentication to websites. Except it's emulated in OS software, and is no longer impossible to clone.
Another way of thinking of it is: It's very similar to using the 'Log in with Google' / 'Log in with Apple ID' buttons you see on many websites, you're authenticating to a service by proving you have access to a cloud account. The implementation details in the background are very different, but the result is broadly the same.
This is the part that makes absolutely no sense to me. An essential aspect of passwords is that they can be changed. If someone manages to fake the digital representation of my fingerprints or face, what now? Security guru Bruce Schneier has written about this w/ much more eloquence and authority.
What kind of failures did you have for the nanos? They just became unresponsive? Did they suffer any obvious physical failure or any particular kind of event cause their failure?
Think an SSH key protected by a passphrase. Your passphrase isn't the thing that actually logs you into the server, its just what you use to unlock your actual key material you use in your SSH handshake. Your fingerprint/face identity is just your local unlock of the actual key material stored in some other secure enclave.
Your face or fingerprint being out there isn’t a concern because that’s not, ultimately, the thing being used to generate the keys or anything.
It’s an ease of use function.
On iOS for instance, as I understand it, these are being stored in iCloud Keychain. Which has a password. The derived key for iCloud Keychain is stored in such a way that the system has access if you allow biometrics to be used.
Biometrics then simply allow access, in essence, not part of the encryption process. The password for iCloud Keychain is necessary to add those items on a new device. Your biometrics aren’t stored by Apple anywhere other than in the device.
Honestly I am blown away how few people on this site understand how this stuff works. It’s fascinating and I’m surprised more people aren’t interested in understanding it. But so many people assume the biometrics are being used in the encryption process and that if your face is somehow stolen your whole life is doomed. These features have been on Apple devices for what.. a decade almost at this point? More? The process for Face ID is the same as Touch ID. Developers make zero distinction between the two in code, as that whole process is passed off to the system and effectively results in a bool value (or access to the secure item requested). At no point does a developer ever get your biometrics data.
I don’t know how Android or Windows do it but it is similar enough I suspect.
The FUD around passkeys feels like some sort of propaganda campaign to discredit it.
I mean there is plenty of FUD, but at the end of the day it's not terribly exciting technology.
But for example if you're using Azure/AD? No U2F + Password allowed, gotta go straight to "passwordless" [1].
So they never took off far enough for Microsoft to support them.
[1] https://learn.microsoft.com/en-us/entra/identity/authenticat...
Seems to me I need to be able to log in with a password from any place (my phone, my machine, my office, my wifes phone, her laptop, my friends laptop, etc.).
I mean, who knows when I'll want or need to get into Something.
Also, my wife and I share accounts (such as Amazon). So, it needs to work seamlessly across all of her devices.
Then there's always the "F-with it factor" that I loathe. At least I understand passwords. Can (mostly) always recover a password (I recall trying to recover my Apple ID password -- they bluntly said "ok, but you have to come back in 2 weeks", so I was locked out for 2 weeks).
And, of course the level of patience my wife has with Technology is less than zero.
I rely on my Safari auto fill, when I use another browser, I just copy the pw from Safari.
And I don't use any of the cloud services. I have an iPhone, but don't use iCloud.
https://1password.com/product/passkeys
The super simple explanation is: SSH keys for websites.
You have a unique private key for each website account stored on your device, in a local password manager, or in a cloud synced password manager (iCloud account, Google account, 1Password, etc).
The website only gets the public key, so unlike password auth your secret is never given to the website.
When accessing that website, the website can send a challenge which your browser answers using your private key associated with that specific domain.
(I'm not a passkey expert and there are a lot more technical details to this, but this is my 10,000ft mental model of what's going on)
First, I had to figure out how to get the website to request the passkey. Then I had to figure out that I didn't want to use the browser's passkey but 1Password's, which is different on different browsers and platforms. And good luck if I'm on mobile, I don't think it's ever worked.
At this point I'm taking a break from signing up new passkeys. I'll stick to UN+PW+(TOTP|Yubikeys).
PS: Why is it that no financial institution lets you use anything more than a SMS U2F?
Passkeys are great for consumers who use one or two devices (or browsers - I also switch browsers frequently). For anyone with more than one platform or one device in their lives they suddenly become added complexity, because even though you _can_ have more than one passkey per account per service, in practice there are all sorts of weird edge cases.
They're just not mature yet, period.
Similar to SSH keys. No reason to use the same key on all your machines, use a different key from different places.
The passkeys on my laptop are different from the passkeys on my desktop which are different from the passkeys on my phone which are different from the passkeys on my main yubikey which are different from the passkeys on my backup yubikey.
Edited due to acknowledging people may choose a variety of alternative workflows.
This effectively makes it impossible to do what you’re saying. It sucks.
Every other site I've come across that supports these things supports multiple. What common sites support only one or two?
If he's storing his passkey in his password manager, it wouldn't matter that he lost the device. They can't get to it, it's AES-somebigassnumber-ed up the wazoo. If the passkey is cached outside of the password manager, then passkeys are a horrible idea, where you have to "go home and call the 800 numbers to cancel the credit cards", and worse still, people with few devices might end up in circumstances where they have no valid devices left to bootstrap access.
I am resigned to the fact that I will die with humanity never having solved the problem of passwords adequately, but being that I will live another two decades minimum, I will get to see two more of the stupidest possible non-solutions.
If an attacker managed to get root on my machine right now, they'd get my whole password safe as its currently decrypted and in memory. However, they wouldn't be able to access any of my passkeys.
Then they privilege escalate, lock out all your other devices after adding a new one, it's the same issue. And it's opaque, reinforces the ideas that users are too stupid to do anything right, so that we shouldn't even try.
Its in-memory on my physical hardware token or a TPM or a secure-enclave, which only activates and unlocks after a valid identity challenge (fingerprint, physical touch, face scan, pin, etc.) not my main system's userspace memory. A massively different target.
So this typically means when I get a new device I'll have my Yubikey in a bag or something with me for a while and pull it out from time to time. Eventually practically every site I use gets enrolled on the new device and I never actually need to reach for the Yubikey or my phone or whatever.
I don't really make any concerted effort to go through each and every account when I get a new device, it'll pretty much just happen eventually. When I do sign up for a new account that supports passkeys I do try and make an effort make a passkey on at least two devices though, often at least whatever device I'm using to initially register and my yubikey. Then I'll make a point to log in sometime in the next few weeks on another computer and create a passkey there. Eventually I'll probably end up logging in and making passkeys on most of my devices.
Needing to auth with an existing passkey is a major part of the model. If you could just log in and create a new passkey with just a regular password, what's the point?
You don't need to log in to every app on every device the instant you register a new account. Just make a passkey on a couple of devices that you're likely to have around and you'll probably have what you need when you need it. When I register on a new site that uses passkeys, I might create a key on whatever computer I'm on and a portable authenticator like my phone or my security token.
So, say I'm at home on my deskop, and TotallyCoolService has the option for a passkey. I'll make one on my desktop, and then go ahead and make one on my security token. Later I'm out and I want to check in on TotallyCoolService on my phone. No worries, I just tap my security token to my phone and I'm logged in. Later I'm in the garage working on my motorcycle and want to reference something on TotallyCoolService on my laptop and my USB token is in my backpack inside. No problem, I can sign in with my phone. Now I've got security tokens on most of my common devices and its not like I had to spend time gathering all of them at account creation.
I don't instantly run home to my desktop and log in the moment I sign up for a new site while out and about. But I do go and sign in eventually, even if only to ensure there's a backup key there.
Whether you do it eventually or do it straight away. Unless you can predict which devices you will have and which sites you will need access to at any given point, then it degrades to needing everything authenticated just in case.
Sure, M devices can be quite large, but the odds of me being at only one device and not any of my portable devices is extremely small. As long as I have at least one other device I've previously logged in to somewhat handy, I can still easily get in. Maybe that initial login is marginally more complicated, but IMO the ease of future authentications more than makes up for the small bit of initial friction the first time.
And in the rare instance where I'm suddenly on the moon and realize I left practically every other computing device and physical authenticator on another planet, I guess I just won't have access to a DnD tool. Oh well.
What allows you to tap your token on your phone and register a passkey-stored-on-phone registered with TotallyCoolService? Did you previously set your phone and token to be "mutually trusted devices" in some way?
Or what's preventing a thief from tapping my token on their phone to register it on TotallyCoolService?
Or you can use a third party password manager like 1Password or KeePassXC.
I feel like most of the replies to your comment talk about the technical aspect of it.
What’s stopping me is that I don’t have a mental model of the management of the passkeys for the whole lifecycle of my account. Can I use it cross platform? Can I allow someone else to use the same account? What happens if I lose or don’t have access to my phone or laptop? What if I die, can my spouse log in my accounts?
With username/password, it’s very clear what I need. I could write it on paper and give it to someone and it’d work. I feel more at risk of losing access to my accounts if I were to switch to passkeys, because I don’t fully grasp their long term lifecycle.
It's my understanding that you can't switch password managers without generating a new passkey for each individual service you use (I'm not an expert here, so someone feel free to correct me). That's already enough for me to not switch.
>Externally there are other issues. 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.
So those are the real risks.
Passkeys are randomly generated passwords that are required to be managed by a password manager. All the major password managers support them, including Apple, Google, Microsoft, Mozilla, and 1Password.
By requiring the passkey to be managed by a password manager, you get some anti-phishing protection. A passkey includes metadata, including the website domain that created it, and the password managers simply won't provide the passkey to the wrong domain. They provide no way for you to copy and paste the passkey into a website, as you can with a password; there's no social-engineering technique someone can use to get you to copy and paste your passkey to an enemy.
A passkey manager is morally required to do an extra factor of authentication (e.g. fingerprint, Face ID, hardware keys, etc.) when you login to a website, but the website has no way of knowing/proving whether that happened; they just get the password.
You reset your passkey the same way you reset your password, because passkeys are just passwords that have to be managed with a password manager. Some sites make it easy to reset your password, some make it hard. You know the drill; there's nothing new or different there.
If you're happy with your password manager, there's no real need to switch, but even very "sophisticated" password users have been known to fall prey to social-engineered phishing attacks.
Are you sure you're never going to copy-and-paste your password into the wrong hands? I don't trust myself that much.
Passkeys can make it harder to switch password managers because the password managers are designed not to let you copy-and-paste a passkey, including from Google's Password Manager to Apple's Password Manager. I think all the password managers kinda like that, and there's something good and bad about it.
https://github.com/bitwarden/server
Like the other commenter mentioned, vault warden is the independent server version that doesn't require any of that.
Vaultwarden + bitwarden client apps (for desktop/browsers) have passkey support, and i've been using them for a month or two without any issues.
That being said, bitwarden client apps for android and ios are going through a rewrite (from xamarin to native iirc), and are yet to support passkeys. However, the bitwarden folk said passkeys are the next feature coming to these apps.
At least that's how I understand it.
But not the second: on Github for example you can have multiple passkeys for the same account.
People mention the "only a single passkey instead of multiple passkeys" issue because they run into some websites such as PayPal that only let you add one passkey. E.g. :
https://old.reddit.com/r/yubikey/comments/14h0d7y/single_key...
https://www.paypal-community.com/t5/Managing-Account-Archive...
SSH keys are asymmetric such that I can make a public half available publicly and then use that to generate signatures of any challenge the server sends.
With passkeys either the server needs to store the value raw(making it susceptible to data breaches or malicious actors), or store the hashed value(making it impossible to do a challenge-response, and making it susceptible to MITM/replay attacks).
It seems to be all the downsides of SSH keys(aka losing it having implications), with none of the upsides, plus additional downsides(hardware devices can only generate 25 unique ones instead of using 1 and sending the public to all services with confidence it hasn't exposed any private info).
This part right here is what I fear the most about Passkeys. I've read too many horror stories of people getting banned from Google (often for no valid reason) and losing access to all of their data. It is absolutely insane to hand over all your passwords to a company like this.
Best practice is to register two keys to every website. Keep one physically in a safe.
With password managers I would say the same basic practice applies. Make sure you have a working offline backup of whatever secrets you hold dear.
There are some sites that only allow you to register a single passkey for an account (AWS Console last I checked) but these should be getting fixed as it becomes more popular
Well, this sounds convenient. Keep the second one in a safe, but register a key to it for every website you use.
Is this a practice we actually believe users will carry out?
I don’t bother with a safe. I have one key that never leaves my home desk and another I have on my keychain. It’s trivial to register the second key when I am home.
Yes it is less convenient than a digital passkey but there is absolutely no way for a remote attacker to compromise it
I think that's what you're getting at in paragraph 3?
There's no reason you couldn't have an open source passkey manager that allows you to backup and view the key if you really want to. SSH works just fine that way.
The reason you couldn't have an open source passkey manager that allows backup is that it wouldn't be a "passkey manager" then, just a password manager. To be a passkey it seems to require that it can't be exported/viewed other than by the website it was created for(even by the user).
Perhaps this is something I shouldn't be feeling, but this bothers me and I do not know why.
I can see that you might not want it exposed to the user to prevent social engineering but at the same time, if I can't view then I don't feel like I actually own it. Is there a mechanism that might exist to help me not feel this way? I am totally new to passkeys as a concept as well, but I understand the larger goal.
https://github.com/keepassxreboot/keepassxc/issues/10407
When it comes to Apple, or Google, remember that people keep their accounts (and therefore access to their keys) at Apple or Google’s pleasure; people’s lives can and do get upended when Google decides you’ve done “The Bad” and they revoke your account-and there’s no learning what you did. For your, and everyone else’s, security of course.
The desire for better metadata is good, because you don’t want to hand your password for microsoft.com to microsolt.com when you’re in a hurry and a sophisticated phishing email arrived. Still, as an example, I’m trusting 1Password less and less. They just helped me autofill credentials somewhere they shouldn’t have (thankfully to no ill effect) when the password was correctly set up with website information, basically where something was site1.example.com instead of othersite.example.com. Because they ignored the subdomain.
Their response from support? “By default 1Password doesn’t take into account subdomains when suggesting an item…” and if you’re using their desktop product, there you can go change - per-item (wtf?) - whether it requires exact domain match to fill.
As so many other people here are saying, it feels like a mass lock-in attempt. If it’s not FIDO is doing a really good job making it look that way, especially with “attestation” (which could just be Web Integrity 2.0 if misused).
Do you have a source for this? After reading the W3 spec[0] this seems entirely antithetical to the Passkey model and additionally raises concerns about the integrity of hardware mfa devices.
That's simply false, and there are passkey managers that allow this - KeePassXC for example.
There are so many apps that don't get this right. Make a login on the website, store it in 1password, and then try to login in their mobile app and it doesn't show up as a password because the associated URL is mismatched on the mobile app. Like mybank.com and auth.mybankmobileapi.com
Better yet, while on mobile, search for the entry of the desktop site and have it fill. 1password will ask if you want to update the entry for this site
I think, finally, that the reason this feels so dirty-apart from companies and lock-in and all-is that it’s taking the “something you know” as one auth factor and turning it into something that, not only do you not know, the big goal of is to make sure you can’t know but something you have.
This is a deep, fundamental flaw in passkeys. It's just another example of enshittification disguised as denying end-user control "for their own good." There is no for-profit organization anywhere that I trust more than I trust myself, and there's no threat model where it's more likely I'll be socially engineered into giving up my long random password than that I'll suffer data loss.
I have vaultwarden at home but I don't use it because I just know I'll fuck up my tunnel while I'm travelling or something.
This is my threat model: "hi mum. I need you to drive to my house and fish a keyboard out of the cupboard. Plug it into the big black box and type exactly what I tell you..."
With passwords and logins, it seems like there are far too many edge cases to draw a hard line to say they are locked in the password manager forever. Having a way to copy it out, or export, is also a way to ensure portability, if the password manager being used ever becomes bad and a different option is needed.
Password managers put users in a vulnerable position, as once a user is invested, they've got you by the short hairs. The thing that keeps this from being a big problem, is that there is always a way out. Eliminating this way out, or raising the barrier to exit, can temp these password managers to extort their users, which is not good.
This is a huge difference from regular passwords, and the source of a lot of confusion about lock-in.
You can’t easily move a passkey out of the service managing it—true. But you should be able to easily add another passkey from another service. Then you deactivate the first passkey.
It’s a different mental model and the key is in the name. Passkeys are like keys. You can have more than one.
It's possible this was a Mac OS problem, but I don't think it really matters. Either way, this stuff needs to be absolutely rock solid and frictionless if normal people are going to use it safely, and it obviously isn't.
Here’s the issue: when a site rejects my password, I understand the potential reasons—wrong site, wrong account, or forgotten password update. But what does it mean when a passkey fails? How can I resolve this? Is it even fixable?
My lone attempt to use a passkey for login involved an unrecognized fingerprint authentication, leading to repeated failures and ultimately, a return to traditional passwords due to the opaque nature of passkeys.
For now, I’ll stick with what I understand.
Phishing resistance is improved over what a good password manager can provide (unique passwords per site, checking web origin before providing options). Since WebAuthn is a protocol, the origin of the requesting site is stamped into the authentication response; even if the user had the option to override a passkey to be sent to a different malicious domain, it is meant to be rejected if replayed on the legitimate website. WebAuthn really needs an attacker to compromise the legitimate site or to compromise DNS and TLS infrastructure for phishing to be successful.
The uniqueness is really two benefits in one - you don't need to think of multiple unique passwords (if doing manual password management), or suffer with password complexity rules (if doing either manual or automated password management). It is just a public key, usually a P-256 curve point. The security of the user authentication process is abstracted upstream, so it is secured with the local password/biometric or via an activation PIN (same as password managers).
The breach resistance means that if XSS gets onto the page, if a hacker gets read-only access to the password database, it is still infeasible for them to leverage anything they gain to answer future authentication challenges. If your passwords aren't unique, a breach is a big deal and can create a lot of lateral movement. Even if they are unique, attacker visibility of the password means account compromise. The private key in a passkey is separate from the website infrastructure, so that attacker is not going to be able to authenticate from anything they observe.
Currently, I view the entire paradigm as asking me to trust resources (software, hosting, etc.) that I am not ready to trust. Both from a knowledge standpoint, or lack thereof on my part, and out of experience. Re the latter, third party resources die, go bad -- technically or morally -- and... just observing the nature of "online" resources over years and now decades.
When your security feature is not as simple as - remember a name and a password and store it somewhere safe - it doesn't work.
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?
SSH is nice because you don't have to think about it. Your private key sits in your .ssh folder, and then everything is transparent. You _can_ put an SSH key in a smartcard if you want, but you have to opt-in to this kind of pain. And even if you do, almost all SSH servers will support that login method without issue.
Passkeys don't sit in your .passkey folder. Your browser doesn't look for passkeys in a standard folder at all. You don't just do passkey-keygen like you would ssh-keygen and forget about it.
Websites might support various combinations of FIDO/U2F/TOTP security keys, your USB security key might support various combination of FIDO2/CTAP/WebAuthn, and the user will be left confused what any of this mess means, why there are so many competing standards, and why they're asked to scan a QR code when they plug in their dongle, and it doesn't just work at all.
The attempts to restrict when and how they are stored, and how you can access them - those are going to cause a lot of pain and confusion.
I have all of my SSH keys stored in KeepassXC, which (imho) is a lot more secure than having them hang around in my .ssh directory. Open KeepassXC, and the keys are available. Close it, and they're gone. Synchronizing the KeepassXC-file across devices means that I have access to the keys on all of my devices.
The big companies pushing passkeys are trying very hard to prevent this kind of convenience.
Password managers have prevented phishing just fine by binding passwords to particular domains, ssh keys prevent phishing with IdentitiesOnly and passkeys are bound in the same way as regular password managers.
Technical people can already be secure using appropriate protections, but even for them it's very difficult to do it properly.
Lay people will, without understanding what they're doing, ask the password manager to give them their password to enter manually on any phishing website as they'll think that it's not working because it's "broken". So , absolutely no, password managers do NOT prevent phishing.
If you think I am exaggerating, well, I work with this and I assure you it's even worse than that.
There has been a pretty insane number of times I've asked someone for their SSH public key and I get a response of ---- BEGIN RSA PRIVATE KEY ----. From people employed in tech jobs. Now imagine someone who barely understands how to use a computer, they're an easy target to get their identity phished.
Passkeys aren't HSMs -- the fact that you can sync them via your iCloud or Google account should dispel any such nonsense. It's fine for Apple or Google to store your keys at your request and they should keep them secure but the model of "here's my key, now don't ever let me look at it but let me use it via what is effectively DRM" is silly.
If a warning message on export "Never share this with anyone. Even someone you trust. Even your IT department. There is no reason anyone but you should have access to this key." isn't enough to stop people giving it away then no security was ever going to work for them. They would give away the credentials that lets them use the key in its absence.
Or just have multiple passkeys for the same account. It doesn't matter if I lose the passkeys on my laptop because I've got other passkeys to those accounts on several other devices.
> Passkeys aren't HSMs -- the fact that you can sync them via your iCloud or Google account should dispel any such nonsense
Resident keys practically are HSMs, aren't they? None of my passkeys are backed up to a Google or iCloud account.
> If a warning message on export "Never share this with anyone. Even someone you trust. Even your IT department. There is no reason anyone but you should have access to this key.
In those conversations with people who should be experts I usually made a point to tell them send me the public key and told them to never share the private. They still sent the public. People have been told to never share passwords either but I still often hear "yeah my password for this is blahblah123..." when asking for help.
We've been storing ssh keys directly on our yubikeys since before passkeys were a thing.
Not only is it clearly more secure it's also been a usability lift. Plugin your yubikey, start an ssh agent, and run ssh-add -K to get all your resident keys added to your current session.
You can recover if you lose all devices via your break-glass backup key, and you limit the blast radius of "my key got stolen" from rotating all your keys to just a single device (or maybe the more likely "I screwed up and pushed my key somewhere public")
I agree that you should use a different key per device, but when you connect to over a dozen different services/machines it quickly starts to become a serious chore to add another key. Have fun spending an hour enrolling your new device - provided you can even remember every single usage it should be enrolled with.
AFAIK there is no equivalent for Passkeys.
So basically we've been storing ssh keys directly on yubikeys the same way passkeys are stored since before passkeys were a thing.
It seemed a clearly superior option compared to letting ssh private keys roam around on random computers.
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.
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 think it depends on the service. But aside from the occasional forum or social site, usernames are just an extra step. I don’t want or need one for banking/administration/ordering a product. For better or worse, email is usually a better identifier, assuming you already need one for other reasons (like you say recovery is typically needed).
> Especially as it reminds them what username they are using for that service.
Like passwords, forced usernames are hard to remember, if you use different ones. If you use the same, then it leaks privacy across services. (Technically usernames can be private but the expectation from decades of social sites is they are public)
> […] loses access to the Usernameless passkey, and then has also forgotten the username for the service
Correct, no identifier at all can’t be recovered. Hence, email.
If you remember which one you signed up with, and it wasn't your work email from two jobs ago.
If you have two passkeys from different providers, they serve as backups for each other. And there are other alternatives, like a printout of recovery codes.
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:
=> 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.
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?
I'm not aware of any restrictions at this time on your second point. I also haven't seen any examples of attestation and Passkeys being used in practice.
They explicitly do not.
We were so very nearly there with U2F... I did extensive testing and you can have a U2F (Fido2/webauthn) device deriving it's private keys, never leaving the device's HSM, from a BIP-44/BIP-39 seed. You write 12, 18 or 24 words down (out of a dictionary of 2048 words) and with these words, you can always reinitialize another Ledger Nano (a cryptocurrency hardware wallet but I didn't care: I was after the U2F "nano app").
It just worked. It was beautiful. My seed were written on paper sheets which I'd store in a safe at the bank / at my parents' home, etc.
As a bonus the hardware device would display, on its little screen, if you were enrolling or login (a useful info) and, for known provides, it'd display the name. For example "login to google?" / "enroll to dropbox?".
Pure beauty.
Then sadly this trainwreck that passkeys are happened, greatly lowering not only the security of 2FA (someone is in control of all your keys and they can be "backed up": what a concept!) but also making you lose the ability to backup your own keys/seed.
I do really hope at some point we see a future "passkeys nano app" for hardware devices on which the user is in control of the master seed used to derive the keys. It worked for FIDO2/webauthn. I hope it'll work again at some point in the future for passkeys.
I wish Yubikey allowed users to import their own FIDO2/webauthn seed and overwrite the factory generated one, and then also allow the resident passkey functionality to be disabled.
It should be up to the user if they want to have multiple duplicate hardware authenticators and be able to backup their seed however they wish.
So yes, I believe your requirements are met in practice.
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.
This will cause a fallback to FIDO/U2F where possible and your browser will appear to not support FIDO2. I've observed this with the default Keycloak flow for Security Tokens. May be a bug, too...
I don't know if this works with Google but if you try it, let me know :)
This needs no restart of Firefox, so you can use it to quickly disable it instead of fully disabling it on your Hardwaretoken.
Why?
Passkeys are always going to be less secure than username + password + Webauthn, why would you intentionally make your account less secure and give yourself a massive failure mode in the process?
> Passkeys are always going to be less secure than username + password + Webauthn
It's less secure in the same way that a door is less secure if you put a single strip of duct tape across that same door. Technically yes, but not in any meaningful sense.
Keys that do not support resident keys (or when you turn FIDO2 off) show differently in Google account settings which makes it all very confusing. The UX is inexcusable, really.
As a side note, turning on Advanced Protection also turns off passkeys.
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.
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.
Edit: I think I found the answer here: https://fy.blackhats.net.au/blog/2023-02-02-how-hype-will-tu...
A key that is reconstructed on the fly is called a "non-resident credential".
You could do it on a USB cryptoprocessor, and securely, too. https://tillitis.se/
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.
I was sceptical about something-you-own auth vs. something-you-know auth from the beginning and recieved backlash from my tech peers for it. I hate to be able to go "told you so" on this one. Lets hope im wrong about the government involvement, but i dont think i will.
You cannot avoid the government.
I don’t think it’s possible to avoid them. Confuse them maybe.
Don't get me wrong - corporate surveillance can be very annoying, especially in insurance / credit scoring / price discrimination etc, but it seems a comparatively lesser danger.
If you decide to switch from an iPhone to an Android phone, you're looking at an arduous process of enrolling a new passkey for every single site.
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.
We had the perfect 2FA method with U2F hardware tokens, why did they have to take that away?!
It deeply saddens me too.
But I think we shouldn't discard one of the obvious reason: the U2F system was too secure.
Let's not forget this: the original U2F system even had a way for the user to know if its device had been cloned, for they'd be using a counter. And they silently removed this.
When Apple+Google+MSFT team up to lower security, I'm pretty sure three-letters agencies and their backdoors aren't very far.
The whole concept of passkeys that can be copied around is honestly hilarious. FFS: we had the perfect solution...
I don't think it's only incompetence at work here: there has to be mischief or at least mischief shouldn't be discarded.
I 100% agree with you but there has to be something for regular consumers to safely log into a website that may have 10s or 100s of thousands of dollars on the other side of it, and be secure.
Which ones? AFAIK they support passkeys in addition to password+U2F 2FA
It still support U2F 2FA, but only if you have a non-FIDO2 key. If you have a FIDO2 key it will use it as a passkey, with no option to change this.
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).
The linked article does a quite good job explaining why hating passkeys make sense.
Here's a key quote, but I do recommend reading the whole article.
> Since then Passkeys are now seen as a way to capture users and audiences into a platform. What better way to encourage long term entrapment of users then by locking all their credentials into your platform, and even better, credentials that can't be extracted or exported in any capacity.
Unfortunately, this scenario is indistinguishable from one in which they deliberately mishandled the specs in order to lock in users.
This is precisely like the imaging standards trying to replace JPG. After two decades of vendors like Google trying to establish a new standard, I can’t send anything other than an SDR sRGB JPEG to anyone, especially to an Android user.
The current post-JPG formats may as well be called “the Apple format”, “Google image”, and “Netflix pics”. There is no practical interoperability to speak of.
I’m seeing the exact same dynamics play out with PassKeys: lip service to interoperability, meanwhile consumers are left twisting in the wind, locked out of their lives because Google can’t play nice with Apple. Or Microsoft. Or anyone else.
“Interoperability is coming” is a statement in the same category as communist dictatorships promising true socialism and freedom… you know. Eventually. Just not now. Or next year… maybe later.
There is a significant amount of interop that already exists, that folks are looking past or just already taken for granted (which is actually fine too!). While on a Windows machine using Edge, you can save a passkey for your Google account to your 1Password vault, and use it to sign in to that Google account on Chrome on Mac (if you have signed in to the same 1Password account on the machines). Or you could use a passkey you saved to your iPhone / iCloud to sign in to the Google account on ChromeOS. This is the level of interop that exists today. This did not just happen magically - all these companies (and more) worked hard to make it happen.
Also speaking for Google accounts, passkeys are an additional option for users. Using a passkey is not preventing you from keeping any other sign in method on your account that you feel has less of the lockin risk.
This is like someone from North Korea saying that they are free because they’re allowed to go to three specific cities in China for work.
Interoperability is an afterthought.
Even if that NK citizen is allowed to go to dozens of foreign countries, he’s still not free. There’s a fundamental difference between enumerated positives and enumerated negatives. Interoperability would be if every combination worked with only a handful of exceptions.
PS: Literally just after I made the comment above I had to add a PassKey to PayPal and only 1 of 4 scenarios that I tried worked.
“Sorry, your browser is not supported.”
Now I will definitely let you have the last word.
Android supports WebP since Android 4, HEIF since Android 8 and AVIF since Android 14. They are only missing JPEG XL, but to my knowledge neither iOS nor Windows support that format natively either. Regarding interoperability and support for open formats Android/Google is way ahead of Apple or Microsoft in my experience.
"Ultra HDR is amazing, but can be only viewed as such only on a Pixel phone. If I'm sending a pic to say FB Messenger it doesn't upload as Ultra HDR." https://www.reddit.com/r/GooglePixel/comments/17n0fkh/ultra_...
Also, unlike Apple iPhone users, people with Android phones tend to get stuck on older major versions and can't upgrade. Easily half of all Android phones out in the wild can't correctly tone map or display either wide-gamut or HDR still images.
You mentioned Android 4 and 8, but full support for wide-gamut (Display P3 and Rec.2020) was only supported starting with Android 14: https://source.android.com/docs/core/camera/wide-gamut
Android 8.1 was the first version to introduce any display colour management at all, which was in late 2017: https://source.android.com/docs/core/display/color-mgmt
As recently as May 2019, there were Android developers blog articles with titled "Wide Color Photos Are Coming to Android": https://android-developers.googleblog.com/2019/05/wide-color...
Similarly, mixed SDR and HDR content (i.e.: not just a full screen Netflix-style app) was supported only since Android 13: https://source.android.com/docs/core/display/mixed-sdr-hdr
If you're enrolling a new device (say you buy a new android phone) you can scan a QR code from your previous phone go log in.
If you want to use both you simply enroll both your PC and your iPhone. There's nothing stopping you from doing this. You can register multiple passkeys from different providers to the same account.
You can also log in to your PC with your iPhone by scanning a QR code. And then afterwards enroll your PC as a secondary passkey.
Unfortunately, the big players are trying to force this (really excellent!) idea into platform dependency. They want to store the keys on physical devices, which (a) eliminated portability and (b) restricts the number of keys you can have. If your device fails, you will also be faced with account-recovery problems.
Great idea, but the implementations are looking...not great.
The problem with storing on-device comes when you use multiple devices. I have three devices (PC, laptop and phone) that I use regularly and interchangeably. What am I supposed to do, if the keys are tied to a single device? Worse, what do I do if that device dies, or is stolen?
I'm not saying syncing is 100% secure (nothing is), but for most people it's not the main attack surface to be concerned about.
If you have both, register two passkeys with each account and that's even better, since they back up each other if the vendor somehow deletes your account.
To get a new passkey on another device, the provider needs to allow you to prove you have possession of your other device first. They can do that by sending you a one-time code, for example, when you authenticate using your existing device, which you can then type in the new device, and that lets you associate your new device-generated key with your existing account.
With iCloud, you don't need event that because Apple can, and does, sync your keychain across all your Apple devices. So as long as you use the same Apple ID on different devices, all passkeys are automatically sync'd.
If you lose ALL your passkeys, you may be in trouble and for that reason, it's common that when you register your first passkey, you should also be given a long recovery code which you must keep privately in a very secure physical location (as that will allow anyone who can get it to reset your account). You could say that IS a password, and perhaps you're right, but there's a difference in my mind that's pretty big: you're never supposed to use that "password", nor keep it easily accessible or even anywhere in digital form.
Finally, a lot of people in this thread are missing that passkeys prevent phishing, and are basically the only way we know to prevent phishing. And phishing is extremely high in the ranking of security issues we currently have to try to solve.
If you know a better solution to phishing than passkeys, please let us know (Passwordd Managers are not that if they allow the clueless user to extract the password and manually enter it anywhere)!
If passkeys are around, phishing will certainly still exist, and shift to dropping malware on endpoints or w/e vs going after logins
Your attack only works on people who basically "trust any website" at all. For those, yeah there's no salvation.
> Finally, a lot of people in this thread are missing that passkeys prevent phishing, and are basically the only way we know to prevent phishing. And phishing is extremely high in the ranking of security issues we currently have to try to solve.
And I can point out several ways phishing is currently prevented without passkeys. And several ways it occurs without logins, such that it’ll still be around after passkeys. And phishing is difficult, but per defense in depth concepts, it is not the mission critical focus you label it as.
So to turn it back around, I don’t think you understand phishing threat vectors well haha.
If you get rid of all knowledge-based authentication in order to increase account security, then you necessarily increase the chances of permanent lockout. You can't square a circle.
As for phishing, maybe google should put its AI capabilities to good use, and if the text of an email matches enough patterns of examples it's seen before, there should be a banner at the top of the email warning "this looks like a phishing attempt: common tactics include X, Y, and Z. Confirm authenticity before reacting to this email."
> how do you get a passkey on a new device when you only have passkey auth on some other device enabled?
You'd use a sync service like a password manager.
Well, not as secure as a commercial key, because the Pico doesn't have encrypted storage, but still much more secure than login/password.
For you, based on what I’ve read in your comments, I would say that Passkeys are the first workable alternative to passwords. They are built on WebAuthn which (roughly summarized) was the standard developed by Google and Yubico in direct response to the Operation Auora attack.
While the Apple/Microsoft/Google implementations of Passkeys likely won’t meet your personal standards, they’re built on a proven and well designed open standard. Which means you can benefit from the technology without buying into a corporate ecosystem.
If you store passkeys in hardware, then yes, passkeys are more secure, but you lose portability.
That's not correct. Passkeys use public-key cryptography and a challenge-response authentication mechanism, so an adversary in possession of a read-only copy of the database of the service you're trying to authenticate with won't be able to authenticate as you - which is very much a security improvement over passwords, even when both are stored in a password manager.
True, but GP is referring to the private key on the (user’s) device or computer being stored in a password manager. The main protection that passkeys offer in such a case is that there’s no case of passkey reuse across services and accounts, which is something that’s possible with passwords even if one used a password manager (albeit poorly by not generating unique passwords for each account).
2: Protection against data breaches since Passkeys are not reused
3: Ability to login to devices you don't own without entering a password (QR code scanning)
Use a passkey on https://www.passkeys.io and it works great! On google too. But use it on PayPal, it does not anymore. Who’s to blame?
How can it be that the website decides which password manager I should use to store the passkeys? That's crazy and goes against all intuition.
With that being said, we are not happy with how password managers have implemented passkey intercepts, but ultimately that's a decision the user can make, as it can be disabled in the browser extension settings.
If you want your passkey to “just work” you have to turn off TOTP. But thats a bad idea because passkeys are an alternate method of auth with paypal, not a replacement for passwords. So then you are left with the option of a password only sign in (no TOTP) or a passkey.
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.
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.
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 too find it hard to imagine how someone can lose all 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.
Passkeys still protect you from additional things that password managers don't protect you against:
1. Your credential can't be phished as it's cryptographically bound to the domain. You could stil be tricked into entering your password and TOTP into a malicious website.
2. Your credential can't be leaked by sloppy servers as it's public key crypto. This makes your security not depend on believing the website your logging into does proper password hashing and doesn't accidentally log password in plaintext.
The dependency on a password management tool.
Be it Yubikey or Apple secure enclave or whatever, it's a shit piece of hardware that will eventually break. Have fun replacing all your credentials at the same time when your phone dies.
I won't have to, because I've got passkeys on my desktop, my laptop, on my security token, etc. Losing one device won't lock me out.
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.
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).
Just FYI it seems the library will still be maintained: https://infosec.exchange/@firstyear/112337225055591544
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.
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...
Being like “I don’t want to add another passkey” is really a semantic issue what exactly is the difference to you or adding a passkeys to an account vs copying a passkey to another device except the fact that if you can copy it/share it… it’d be far less secure with more ways to leak
My partner and I share a single account for XYZ service. We don't want separate accounts.
> it’d be far less secure with more ways to leak
There is nothing "less secure" with sharing an account credentials with my partner through bitwarden. Especially for accounts that are things like "pay my electric bill" or "online shopping".
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.
Adjacent to this, I really liked Steve Gibson’s SQRL. I wish that had taken off.
That is my main reason for avoiding Passkeys;
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.)
What also worries me however, is that apparently if i read correctly, each server/service/website can decide/restrict "which password managers/apps" are allowed to be used for the Passkeys they offer...
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.
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.
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.
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.
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.
So please FIDO'S contributers, find away to standardize backup&restore passkeys.
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.
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.
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).
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.
But the more I wanted to use Passkeys are more scary it got, basically the gut feeling of losing control.
If we could use something akin of derived, reproduceable-ish (???) Passkeys maybe then.
As of right now it feels wrong.
I've got my sheet in my gun safe, but you can also hide it anywhere in your house.
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!
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.
That you can always just copy them out, put them in a different password manager, or write them on a post-it.
That said, I think this is a byproduct of the design space being complex (as you suggest) and not, as the author seems to feel, "thought leaders" or malice.
My conclusion so far is that it's a promising technology, but no way as mature as I'd like it to be. Unfortunately we are stuck with emails and passwords for the foreseeable future, at least as a back-up mechanism for credentials recovery, which, funnily, makes the whole thing pretty much pointless.
You have to beat email/password with optional password manager (syncing, remembering , autofilling) and optional MFA (physical proof)
passkeys cant beat that in any area because they have no goals
With passwords it's fairly obvious. Even if you don't know about password hashing, semantically it is the same as how you would obviously expect. Same with password managers. It's obvious what they're doing.
So I think this would fail even if it didn't have all the problems the author mentioned - it's simply too complicated for normal people to understand and trust.
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 of course.. there's no standard API for them to implement it. Instead, vendors are patching the WebAuthn APIs using WebExtensions.
This is sabotage.
This is the same Credential Provider API they already have to integrate with to show the password autofill in iOS so there is already _some_ code for this.
1Password _could_ just integrate with the native UI. But they chose not to. This however means shipping a native app which is a lot more heavy-weight than shipping a web extension.
I opened an issue in the webauthn repo about giving an API for WebExtensions to hook into the passkey autocomplete but there hasn't been any traction or appetite for it unfortunately :(
I mean, I kind of understand this; they're going to have to do the WebExtension either way, since there's no standard API across platforms.
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.
But this would be a lot worse if it were your only way of logging in. Always have multiple authentication methods for important accounts.
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.
Also, smartcards had usernameless for 30 years.
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.
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.
'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).
'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.
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.
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 (plural) come organically without a single player controlling the conversation.
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.
The most obvious explanations seem to me to be:
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.
b) The author is doing something weird.
c) This is hyperbole.
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?
Firstly I spent weeks chasing down what I thought was a data loss bug in iCloud. After much effort I managed to reproduce it. Turned out it was an issue with TeXshop rather than iCloud.
Secondly, the one time I had a photo lost, it wasn't lost. I just couldn't find it in the 12000 photos I had. It wasn't where I'd left it.
The third one was a data loss bug, was reproducible, was reported to Apple and was fixed. This was due to how Numbers handles three devices and how it decides the winner of a conflicting change and was an edge case as number 1 awkward customer.
YMMV but user testimony may be as reliable as eyewitness reports.
But the implication that Keychain just kind of forgets saved Passkeys once in a while seems alarmist and probably unfounded.
I will say that there are some very well known backup and restore issues with keychain however so I keep anything critical in MacPass as the primary copy.
So what happens if you want to migrate away from iCloud for the storage of passkeys?
This is not different at all from a SSH public/private key combo. You are not supposed to duplicate SSH keys!
1. Most services are not Passkey-only--most people are using it as a password alternative (e.g. eBay) or a second-factor alternative. So losing it won't lock me out.
2. A very small number (e.g. Google) let you configure Passkey as your sole second factor. For those, I am indeed careful to do what you do and have duplicates.
I do think this is kind of bad? So the grandparent totally has a point here: services find it hard to do only Passkeys (and thus realize the security benefits).
But, as a user, it's not something I worry about a lot, to be honest.
I could stop using my idevices tomorrow and not be negatively influenced.
The author is the main dev of an identity management platform and called kanidm, so yeah I'd wager their usage is fairly non-standard. That said, it should be almost impossible for it to happen anyway.
Also, that doesn't apply to his partner.
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.
did anyone encounter this issue? is it logged somewhere?
i seriously considered dropping passwords completely for future projects, but it looks like there are still issues…
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.
> For devices like your iPhone or Android, you would do similar - just use your Touch ID and you're in.
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.
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.
While Passkeys are an interesting development, it will take time before they are part of the authentication routine of standard users.
[1] - https://arstechnica.com/tech-policy/2024/04/cops-can-force-s...
- credit card sized
- completely airgapped
- standardized
- controlled by a non-profit association
- hard- and software open sourced
- built-in camera to scan data
- built-in display to show data
- configuration mode: scan human-readable configuration
- data is QR code or something like Base58 to copy by hand
- backup by supporting applications: scan and print out data
- browser integration by an extension using a webcam
https://en.wikipedia.org/wiki/OpenPGP_card
In fact the Estonian Id-Card is one of these if I'm not mistaken
within a business where we have policy around what devices may be acceptable the ability to filter devices does matter.
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??
Hmm...
"As of Q3 2021, 37.0% of internet users worldwide use ad blockers, according to GWI data cited by Hootsuite." https://www.emarketer.com/insights/ad-blocking/ "
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.
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.
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.
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:
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.
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.
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 that confused when their unsupported key doesn't work.
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?
But even if on balance the tech is worth implementing, it’s clearly not easy and your suggestions to “just” do several things that aren’t happening ring a little hollow.
Points #1 and #2 are not entirely trivial, but they're not much more complicated than the alternatives. A relying party has to store the public key counterpart to a user's private passkey no matter what. Is it really that much harder to associate that public key with their user ID? Point #2 is probably the hardest to overcome if you already baked in the assumption of 1 key per user. That's concerning. But that problem can also be mitigated by the authenticator, by supporting export.
I'm not saying the article fails to identify real issues. I'm saying it fails to identify insurmountable issues. The nice thing about software is that a good canonical implementation can be used by everybody for free.
1. SSH keys, as they're normally used, let you be tracked between hosts. That's fine for SSH, because nobody's trying to SSH into their Grindr account. But for web login stuff you want a different key pair for every site.
2. Adds a bunch of 'attestation' features that corporate types think they need.
3. Tries to make it so an attacker who gets access to your machine can't make a copy of the credential. The success of this is implementation-dependent.
4. With barely any setup, Google/Microsoft/Apple will keep a backup copy, in case you lose your phone. This is useful for non-technical people.
Not Microsoft. Their implementation has no synchronisation feature and provides no way to back it up or transfer to another device either. You lose the computer you lose the passkey.
Their implementation is very daft and goes counter to the point of passkeys since you will need a less secure way of authentication to remain enabled on the accounts you use a Windows Hello passkey for, for the sake of being able to recover those accounts.
Remember, the best security schemes are only as secure as the least secure scheme that is available to access the account. If you're still on an account that can be recovered by sending a 2fa code to email or SMS/texting then you have achieved nothing.
So, yeah, useless technology for now. Passwords and TOTPs are the way.
Personally I love the convenience of passkeys (coupled with 1Password pw manager), however, for whatever reason it doesn’t “feel” like Passkeys replace passwords but rather they complement them. I treat Passkeys as ephemeral—it is lovely when they work, but sometimes I still need to fallback to trusty ol’ password login.
As long as the server supports the device/protocol/options you want, and doesn't enforce attestation against a small list of enterprise vendors.
For instance Microsoft Azure AD's Entra ID authentication service, the one that keeps changing name, has a hardcoded list which you can consult here: https://learn.microsoft.com/en-us/entra/identity/authenticat...
In theory there's no vendor lock-in. As long as Azure adds your vendor to the Azure-approved list, and as long as every other provider refrains from making their own list.
For the Apple/Google ecosystems specifically, it's also important to keep the compatibility matrix for each service in mind. For instance with Azure again: https://learn.microsoft.com/en-us/entra/identity/authenticat...
In theory any FIDO2 implementation could work with any service that accepts passkeys. In practice, compatibility matrices and allowlists are the reality.
No, TOTP and passkeys had different motivational concepts:
- TOTP Time-Based-Onetime-Password of a "rolling numeric code" is conceptually similar to "trusted hardware" such as RSA SecurID tokens: https://www.google.com/search?q=securid&tbm=isch
- passkeys are conceptually similar to "trusted hardware" such as biometric USB vault from Yubikey that cost $50: https://www.yubico.com/product/yubikey-5-series/yubikey-5-nf... ... or Nitrokey: https://shop.nitrokey.com/shop?&search=nitrokey%203
In both cases, you can put secrets into the hardware but can't extract them back out. You can _use_ the secrets stored in the hardware via your fingerprint to facilitate logins but you can't extract/copy the digital data from one Yubikey to another Nitrokey. This restriction for USB vaults is deliberately designed for security but typically isn't disparaged as "vendor lock-in"
However, increasing website security via "trusted hardware" by making everybody spend an extra $50 for a USB vault is not ideal. Instead, a bunch of security experts noticed that billions of people are already carrying smartphones that have built-in biometric security such as face-id and fingerprint readers. Ok, let's just piggyback on existing smartphones and make them "act like the $50 Yubikey/Nitrokey" -- which means mobile passkeys managers like Google not allowing simple export/copying of passkeys.
Yeah but desktop managers like 1Password, Bitwarden, KeePassXC allow export of passkeys! True, but there's controversy and disagreement about that because they're not restricted like the Yubikey hardware is. Will some websites that are very strict reject some clients that allow passkeys export? It's a wait & see.
If the "ideal" passkeys ("ideal" from the RP Relying Parties point-of-view) are for them not to exportable/transferrable to another device, how do they expect people migrate from Apple to Android or whatever? By generating new passkeys for that new device and adding it the list of approved passkeys the website accepts. Instead of transferring the secrets, you re-generate new secrets.
This feels like the best advice, imo.
What's wrong with these Aussie technocrats?
People get angry or frightened. It's better for everyone else if they're not carrying a firearms at that point.
Policing a nation where everyone is armed means the police are heavily armed and the non-insane ones very frightened all the time. See above.
Rape rate is about 3x the rate of EU: https://www.civitas.org.uk/content/files/crime_stats_oecdjan...
People killed by police (population adjusted) is about 30x the rate of Germany: https://www.statista.com/statistics/585152/people-shot-to-de... https://polizeischuesse.cilip.de/?p=1&year=2023
- "Violent crime is more common in the US than in Australia"
- "Medical costs in the US are extremely high. You may need to pay up-front for medical assistance"
I think some Americans don't realize that, outside of America, many people don't ever consider the risk of gun violence in their day-to-day lives, or owing thousands of dollars for visiting a hospital.
As for the medical costs - if you want to be on the safe side, you can (actually you should) get travel health insurance.
You have to read your insurance contract and info sheet properly rather than go for the lowest price.
Though you might need to get a US specific one. Mine contains a clause that specifically excludes the USA from coverage, and that’s not uncommon.
Note I live in London and everyone tells me I'm going to get stabbed too and die from the pollution...
That's an 0.006% chance of getting murdered killed in NY every year.
And that doesn't account for (a) putting yourself in a good position to get killed like being a gang member and (b) the aggregate reduction in risk by only travelling there.
Quite a few people don't want to deal with that.
Most of the world sees the United States as a dangerous country.
For example, using the source you've just given, the US homicide rate is over 5 times the homicide rate of the United Kingdom, France and Germany, and over 10 times that of Norway.
Granted, you're more likely to die in a car accident than to be murdered in the US, but that's no reassurance; this is partly because the vehicle accident mortality rate is so high in the US, at over four times the rate in the UK. And your comment about dying in a plane crash is completely wrong: the air travel mortality rate is very close to zero, with under 200 deaths for over 800 annual million air travellers; a rate of less than 0.025 per 100,000 per annum.
What is not is walking 30km in the middle of nowhere in Central Asia because you didn't have enough cash to pay the driver's bribe. Stuff like that is a far more realistic concern than the security border paranoia stuff that goes on. Know where you are going, plan ahead and stay out of obvious trouble. That applies everywhere. The US is not special.
(Incidentally when I got to the first town, the guy in the shop laughed at me and invited me in for tea and dinner on him and his wife and I got to learn all about their history under Russia - it's not all bad)
As an Australian, seeing it on the news the next mornings made me very, very uncomfortable.
I understand that these shootings are unlikely to ever involve me, and I’m not discomforted to the point that I won’t go back to the US, but it is worth understanding that gun crime in the US is seen as uncomfortable and concerning to many. That my US friends who were at the same venues with me were completely blasé about it left me a little nonplussed.
"I'm Australian so I wont be attending either (I am not comfortable to enter the US due to a preexisting medical issue)."
That's the "Medical costs in the US are extremely high. You may need to pay up-front for medical assistance" part of the text.
I do not know if travel health insurance generally covers complications from a pre-existing condition, and as other mentioned, getting travel insurance which covers the US is already a special case.
I like passkeys as idea for stonger security, but author somehow thinks that discrimination against devices is a good idea.
Sorry, no. Just no. I dont want my bank or paypal require me to use iPhone in order to login to my account.
The problem is that browsers are infamous 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.
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).
Honestly I'm just relieved this appears to be crashing and burning on the runway. Crypto bullshit's gone through several destructive hype cycles by now and the main consequence of the latest round of the AI craze will be a nuclear wasteland of an internet.
Please.
only passkeys is a problem
Enshittification in a nutshell. The victory of greed over utility.
I get the capitalist inclination and desire to make things easier for people (and often infantilize them) but this just ain't it.
There is no easy 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."
Sometimes you just know when a thing isn't practically feasible.
There is nothing wrong is passwords.
There is everything wrong with biometrics.
Wake up!