Passwordless Google accounts are easier and more secure than passwords. Here’s why.

The passkey ecosystem is far from complete, but Google's implementation is now ready to use.

See full article...

 

[randomuser42]

Talk about overlooking. "Somewhere safe" means "somewhere only I can get to after authenticating". This is like saying that I need to keep the spare key to my safe in my safe.

Also, how is the hard copy going to help when I'm abroad and can't get to it?

If you're traveling and need guaranteed access to a 2FA protected account then bring the codes with you. They can be changed when you get home if you're worried about it. If you're worried an adversary is going to be able to target you specifically and get those codes and your (strong, unique) password simultaneously, well then there's probably not really anything you can do.

Your other alternatives are to bring a device that doesn't need 2FA and leave it in your hotel (and if your adversary is so sophisticated that they are targeting your hard copy codes and have one password already then that's not going to work!) or disable 2FA which is, obviously, worse.

 

[SeanJW]

So does this protect against malware grabbing browser cookie info on devices once logged in? If I logged in this way today on chrome on a windows PC, does it auto log-in tomorrow without the passkey being re-input, which would create this security risk? Or does it require logging in every time, more secure but probably not favored for usability by less security aware users?

Nothing prevents that. This is before the session cookie is even created stuff.

 

[karinto]

Ars needs to do a technical overview article for passkeys. There are so many misconceptions about how it works in the comments here...

 

[Offbit]

... the answer is in the question: Google.

Why would I trust an organization which is a multiple privacy violations relapser, and who, by law, must provide my data to US authorities whenever they feel like it?

 

[Deleted member 853683]

Ars, what I never see addressed in these articles are mixed use and multi use devices.

I use an Android phone. I use chrome I have office 365 on my phone for business and only business. How can I authenticate just business without giving up personal info. Or the other direction

At work I use three browsers. Firefox if I look something up personally, chrome for our erp system, and edge for work related web lookups each one gets different logins and stores different logins.

If you sign into a single ecosystem these systems work okay. Until they get canceled

1Password, Bitwarden, and other password managers are working on support and will probably be released later this year based on what they've signalled. Do you use these services, or another password manager? Then in theory it will be just as easy once that capability rolls out.

You can also have multiple passkeys if the service supports it. My Google account has both my Apple and Windows passkeys stored on it. Both work fine.

Unless your current approach is to remember a handful of passwords you use everywhere, or put them on sticky notes, cross-platform support is going to be a non-issue in the fairly near future.

 

[BasP]

If you're traveling and need guaranteed access to a 2FA protected account then bring the codes with you. They can be changed when you get home if you're worried about it. If you're worried an adversary is going to be able to target you specifically and get those codes and your (strong, unique) password simultaneously, well then there's probably not really anything you can do.

Your other alternatives are to bring a device that doesn't need 2FA and leave it in your hotel (and if your adversary is so sophisticated that they are targeting your hard copy codes and have one password already then that's not going to work!) or disable 2FA which is, obviously, worse.

Bringing those codes with you as you travel does NOT sound like a safe place to keep them.

Also keeping a second (non 2FA) device isn’t going to help. Either the stuff I need is not going to be on that device, or it is, which means it is kept insecurely since you don’t need 2FA to get to it.

If my 2FA account is also accessible via a password, then it might as well not be 2FA because it has a way easier attack vector in the password.

 

[dangoodin]

No, it's cross platform support is trash and that doesn't really work. So, wake me up when they get it right, I'll keep using these yubikeys.

What's the basis for saying the cross-platform support doesn't work? Can you describe where things break down and maybe provide a screenshot or two to illustrate? Also, when is the last time you tried the cross-platform mechanism? As you can see from the 2019 article I posted and linked to in today's post, I too once had criticisms. Since then, things have changed considerably under the hood. For instance (and as also noted in today's post) the Bluetooth communications have been stripped to the bare essentials. That makes it much easier for your devices to connect.

 

[SeanJW]

Doesn’t that make passkeys kind of useless? I mean, now you have a non-passkey attack vector.

Apple currently requires 2FA just to log in as far as I’m aware, and just the iCloud login is not enough to iCloud Keychain sync - it either gets approved from another device (I think), or you use the device unlock code from a device that did or does have access. So if your iPhone catches fire, you can still use its old unlock code to get into keychain.

 

[adamsc]

It’s a matter of perspective. Security experts worry about a third party getting into their stuff. Non-security experts worry about accidentally irreversibly encrypting all of the family photos.

Those are both part of the same problem and they overlap almost entirely. People want their stuff to stay secure (not lost, not ransomwared, etc.) which means they need to worry about authentication. We have decades of failures related to the technical drawbacks of passwords (mostly that humans suck at generating and remembering them, and they can easily be replayed) so people have tried bolting on various multi factor schemes of varying levels of effectiveness, but all of that produces a system which is hard to use and is still compromised on a daily basis.

The goal of WebAuthn is defeating phishing while being easier to use than the older systems. That doesn’t mean companies don’t need anything else to handle account compromises or lost access, but that was already the case as we saw during the pandemic when a bunch of companies started adding things like legacy contacts.

 

[meisanerd]

So, after playing with Google's implementation of passkeys for a couple days, it seems to have improved slightly vs when I first set it up on release day.

I'm using a Yubikey for this, not Android or iOS. This means that I am not beholden to Google/Apple to be able to manage my key, nor do I have to worry about my account getting compromised and thus leaking the passkey.

As a point of comparison to the Google Account login, I have also been using this Yubikey to access my Microsoft account for a while now.

Microsoft works across all of the major browsers on desktop (except Safari on MacOS last time I checked). Google seems to need Chrome.

Microsoft has an option below the username field to sign in a different way, then you select Windows Hello or Security Key, put the key into a USB port, enter the PIN, and press the button on top. It will then ask you which account (if you have multiple accounts saved), and you are logged straight in. You don't even need to remember your username/email address.

Google requires you to enter your username/email, then it asks for the key to be inserted. You then need to enter the PIN, and it logs you in.

From a usability perspective, Microsoft is better in that you don't need to remember your email. For the Ars crowd, this is probably a negative. But if you are supporting 70 year old grandparents, the less things they need to remember, the better. I haven't confirmed, but a downside to the MS system is that the Yubikey only supports a specific number of stored credentials, whereas from what I could see in my research, the Google method basically has the Yubikey generate a private key specifically to that site based on an internal private key, your PIN, and some information provided by the site and the browser, every time it needs to run the authentication. Both of them seem to use an internal private key specific to the Yubikey, your PIN, some information about the domain provided by the browser, and specific information provided from the site you are visiting to perform the handshake, which prevents MITM attacks from being successful as they can't spoof all of that data.

I'm not sure what is missing in Firefox for the Google implementation vs the Microsoft one, why it doesn't support the new passkey system. Or is it just Google not requesting the passkey because Firefox hasn't implemented the Bluetooth portion, which has the side-effect of not supporting Yubikeys/hardware tokens because Firefox isn't being asked for it by the Google login site.

--

If you lose the passkey and do not have a backup passkey, the security fallback is to log in the way you were logging in before the passkey. So usually password + OTP. While this means the site does support a less secure authentication system, one advantage is that you aren't using the password on a regular basis, so it is less likely to be leaked or intercepted by a phishing/MITM attack.

--

From a security perspective, you can view passkeys as a password wallet with limited site support. If using a Yubikey, the wallet is a hardware device in your pocket, protected by a PIN. If using the Android/iOS passkey, the wallet is synced in a cloud system and protected by your account password + biometrics. If you lose the device, it is similar to losing the password file.

Once they get all of the kinks figured out, this has the potential to change a lot of things in the security landscape, as non-security-conscious individuals will no longer be resisting secure password requirements or having to figure out how to properly use a password wallet, and how to access/sync it across multiple devices. By basically becoming a password wallet, the passkeys generate really secure, really random passwords for every site they are used on, and are built with phishing-resistance in mind.

 

[dangoodin]

I'm not sure having to go find your phone, find the app to scan the QR code with, I guess you'd have had to go thru some setup for fingerprints...and hope it accepts your fingerprint (I have issues with fingerprint unlock on the devices I've tried it, such as after working in the yard or on the car it won't accept until my skin heals fully for several days).

That doesn't fit what I would call "easy"

It's a shame this post is so highly upvoted, because it's based on a fundamental misunderstanding. You need to have your phone to scan the QR code exactly once when logging in from a new device. After that you won't be "having to go find your phone. As for having to "go thru some setup for fingerprints," anyone who has set up Face ID or fingerprint scanning on their Mac, iPhone, Android device, or Windows computer has already done this. And if your device doesn't support fingerprint or face ID, you can always simply enter the unlock PIN.

tl;dr: despite all the upvotes, this comment is misinformed.

 

[randomuser42]

Bringing those codes with you as you travel does NOT sound like a safe place to keep them.

Also keeping a second (non 2FA) device isn’t going to help. Either the stuff I need is not going to be on that device, or it is, which means it is kept insecurely since you don’t need 2FA to get to it.

If my 2FA account is also accessible via a password, then it might as well not be 2FA because it has a way easier attack vector in the password.

Realistically, the threat profile of someone physically compromising the codes AND my password simultaneously (all in the window before I get home and change them) is pretty miniscule, and I'd challenge you to explain how it isn't.

But, if the threat is too great for you that's fine, then you can not guarantee access to any 2FA protected account while traveling and your concerns about losing your phone down a well don't just apply to passkey but every account that is protected.

 

[SeanJW]

This is why everyone has issues with all these articles. Some claim bluetooth is required for proximity verification, others say it isn't. The "official" documentation is severely lacking, the password manager documentation doesn't actually state one way or the other. This seems like an incomplete integration.

Bluetooth is required for proximity for the QR code dance with your phone.

Good news! You don’t have to use PassKeys. They’re just FIDO2 authentications, so if a site so provides, you can use a hardware key with no Bluetooth at all. Google currently won’t allow you to do that for passwordless login I believe, though it might if you set a PIN on the hardware key, or it has biometrics. Anyone can try if they want.

 

[dangoodin]

From the article:
"Some passkey skeptics have expressed concerns about entrusting Apple, Google, or Microsoft infrastructure with the secret key. Some of these critics have gone so far as to say that passkeys are a power play designed to give these companies control of authentication secrets not previously possible. These claims simply aren’t true."

For me at least, this is a mischaracterization of the concern. There are horror stories for example (reported here on ARS) of Google disabling a man's account for sharing photos of his child with his doctor. If all of my passkeys are tied up in Google's ecosystem and something like that happens, I'm totally screwed and would be unable to work.

The solution is simple enough though: don't trust a hardware vendor, instead only store passkeys in something cross-platform and open source like Bitwarden. For me, that is the only way that I am going to start using passkeys.

Edit to add:
Yes I am aware that Bitwarden does not have full passkey support today. It is in the works:
View: https://www.reddit.com/r/Bitwarden/comments/136j90t/did_you_know_bitwarden_is_working_on_passkey/

I don't understand your reasoning. Under today's password paradigm, Google can suspend your account anytime it wants. How does using passkeys make it easier for Google?

Also Google passkeys ARE ALREADY cross platform. My Google passkeys are currently being synced not just by Google, but also through the iCloud Keychain and Windows Hello. As you note, Bitwarden, 1Password and a bunch of other third parties will soon also provide syncing.

What's your basis for implying Google passkeys aren't already cross platform?

 

[adespoton]

I've got 4 Google accounts. I've enabled this on one of them that's only ever used on one phone/laptop by one user.

One of them isn't getting it because it's an anonymous account I don't want slaved to a real ID.

One of them isn't getting it because it's a shared account that multiple people need to access.

One of them isn't getting it due to not trusting Google.

 

[dangoodin]

Passkeys are cool and fine. But no, I will not be using one from google, et al. I'll take something that is fully open source and lets me maintain independent backups of my keys, thank you very much.

So you don't use Windows, iOS or macOS, just Android and Linux?

 

[BasP]

Realistically, the threat profile of someone physically compromising the codes AND my password simultaneously (all in the window before I get home and change them) is pretty miniscule, and I'd challenge you to explain how it isn't.

But, if the threat is too great for you that's fine, then you can not guarantee access to any 2FA protected account while traveling and your concerns about losing your phone down a well don't just apply to passkey but every account that is protected.

Why would they need to compromise the codes and your password? If you can access the account using a password, they can just compromise the password, right? Or do I misunderstand what you mean?

The problem of dropping my phone down a well is not a problem if I only use a password. Then I just buy a new device and log in using the password.

 

[Deleted member 174040]

I don't understand your reasoning. Under today's password paradigm, Google can suspend your account anytime it wants. How does using passkeys make it easier for Google?

Also Google passkeys ARE ALREADY cross platform. My Google passkeys are currently being synced not just by Google, but also through the iCloud Keychain and Windows Hello. As you note, Bitwarden, 1Password and a bunch of other third parties will soon also provide syncing.

What's your basis for implying Google passkeys aren't already cross platform?

It would be nice to hear a response to this, but we all know…

 

[Deleted member 853683]

... the answer is in the question: Google.

Why would I trust an organization which is a multiple privacy violations relapser, and who, by law, must provide my data to US authorities whenever they feel like it?

Are you talking about storing your passkeys in Google's ecosystem, or using a passkey to secure your Google account?

If you store your passkeys in Google's ecosystem, then it's no different from using Chrome to manage your passwords. Don't want to do it? Then don't. You can use other services - Windows can store passkeys, Apple can sync everything across all your devices automatically, and 1Password, Bitwarden, and others are working on supporting passkeys as well. I'm sure we will eventually see a FOSS option for those who don't want to trust anyone else.

If you are talking about not wanting to secure your Google account using a passkey because "the Feds could get in", then sure, I guess. But if you're that concerned, then I regret to inform you Google already has your data, so...

 

[Jarrex]

I think it's simpler.

Big tech wants to kill passwords because it is a significant cost. Compromised accounts represent a major customer service issue. It stops people using their services, it makes people lose their important and often highly personal data, and it's expensive and time consuming to fix. It's why Google, Facebook, etc. are so keen on pushing 2FA and want to make it as close to mandatory as possible. Current 2FA significantly reduces these security issues - but it also comes with a host of UX problems and compromises. In the long run, passkeys eliminate a lot of those drawbacks while also providing a better UX.

Remember that we've been using passwords since basically the dawn of computing - yet we still routinely see major mistakes made in their implementation, even boneheaded stuff like companies storing them in unsecured plaintext databases. But even then, it was a couple of decades until we had really got a lot of the issues sorted out, and truly good password managers emerged. Passkeys are going to take some time to sort out the issues as well.


Also, come on, the accusations of astroturfing are just a little bit ridiculous. You do know how tech news coverage works right? Why is a tech news site covering a new technology suspect? Isn't that why you're here?

If I do have an issue with the reporting around passkeys, it's the suggestion that they are now ready for primetime. I think they're neat and possibly worth using for the types of people who are inclined to read tech news about login security... but average users, today, not so much. At the same time, they also won't get there if people don't know they exist, so there's definitely benefit in getting the word out.

Ars alone has published 5 Passkeys are killing passwords articles in 7 months. Three of which are in the last week. That's not just covering new tech stuff, that's pushing a narrative. Look at the non-tech sites saying "Google and Apple are killing passwords!" It's been going on for the last 1-2 months pretty constantly on the same websites.

Not only that but every single article lacks actually talking about the tech aspects -- which is easily seen by the fact that nobody actually can point to a diagram and say for sure "yup this is how it works". Bluetooth required? Yes? No? Who knows. Even you say it yourself that they are all saying it's ready for primetime.

If it's not ready for primetime, why are sites like ars pushing it like it is? Why is it on this perpetual news cycle with nothing new about it. There isn't any new details about it yet here we are, talking about it again.

 

[alastairmayer]

Not only no, but fuck no. Especially not from Google.

 

[Aldric]

Complexity concerns aside tying this to biometrics would enable warrantless access to accounts wouldn't it? It's already precedent that police can compel you to unlock your phone with biometrics but not force passcodes or patterns.

I realize other methods have these same limits, but this seems like a step back for privacy overall.

 

[adamsc]

How is this multistep process easier than filling in a password?

Well, think about what filling in a password actually means. If you don’t use a password manager, you have to remember and type in a password – and since each site has different rules about things like rotation, you have to periodically memorize new ones. If you use a password manager, you don’t have to remember the password but you do have to deal with various auto fill bugs and when changing passwords you have to adjust the more secure password generated by your manager to whatever weakening rules most sites enforce, and make sure that you save the updated password everywhere and don’t end up with multiple copies or problems around failed update workflows. For example, I use 1Password and not infrequently hit something like where I save a new password but the site had different validation rules than their form claimed so I have to edit it but 1P doesn’t pick up the change & save it unless I manually edit its database. You can also get similar problems with big companies migrating around so the password I have saved for www.bigcorp.com is wrong and I have to pick www2 until I manually merge that entry or delete the old one.

In contrast, here’s what a passkey is like to register or use:

1. Hit enter or tap to confirm I want to use my passkey on that site

 

[shadedmagus]

There are many more options for using passkeys than critics commenting here realize.

So then, Dan, how about an article showcasing those options?

Many of the criticisms so far are based on fundamental misunderstandings about passkeys. Going forward in comments, please don't criticize if you haven't tried it first.

I think pushing people to use passkeys without a detailed understanding of exactly how they are better to use than passwords, along with pushing while the environment is still being developed, gets you exactly the kind of pushback you're seeing in this thread.

 

[MisterXman]

What happens when I buy a new Android phone? I mean how do I add my Passkey to my new phone so that my account transfers over to my new phone?

 

[Beyond Opinion]

My phone is...usually somewhere in the house, though I regularly have to call it from a landline or use the "find my phone" to play a noise to find it probably once a week or so. And sometimes I am in a hurry and forget it on my way out to work.

And I work in a place that doesn't allow personal electronics so I have to use the company-issued devices when I'm at work and the personal phone stays in the car or a locker all day. Which is partly why I don't miss it THAT much if I forget it at home. Slightly more annoying if you forget it in the locker at the office and don't realize until you get back home without it.

Though that still doesn't solve how often fingerprint unlock fails across multiple devices of multiple brands, and I mostly ignore it now because the pin is faster and more reliable to type.

Yeah, fair enough. I get that this won't work for everyone. And I'm not even in a hurry to jump on it; I'll wait to see more support from vendors other than Google.

 

[SeanJW]

It's a shame this post is so highly upvoted, because it's based on a fundamental misunderstanding. You need to have your phone to scan the QR code exactly once when logging in from a new device. After that you won't be "having to go find your phone. As for having to "go thru some setup for fingerprints," anyone who has set up Face ID or fingerprint scanning on their Mac, iPhone, Android device, or Windows computer has already done this. And if your device doesn't support fingerprint or face ID, you can always simply enter the unlock PIN.

tl;dr: despite all the upvotes, this comment is misinformed.

That’s not quite true. You will need to use the phone/QR every time you log into a site, unless you do the login process, then add a new local authentication (which can be Passkey or old platform specific - Google conflates the two for convenience, but they are different).

Chrome (and I assume Edge) can add one on Windows and macOS. Chrome can also do it on ChromeOS. Firefox can apparently do it on Windows, but after fighting Firefox enough I gave up caring enough to try.

I’ve been developing and using FIDO2 authentication on web sites for a few years, have sweated bullets over it, and sworn many times over hardware keys not being recognised. When I add support, I’m very forgiving of what keys are accepted, but a site doesn’t have to be - there’s all sorts of features they can require of a key, and even specific device IDs if you want. Most devices actually offer a null ID, even when asked nicely, but Yubikey 5 give device IDs, so it’s easy for a company to order from yubikey and know that only devices they issued and support are used.

Now, there’s usually no reason to not add “yet another key”, except some stupid sites limit how many keys they support. So you might end up doing the phone/QR thing more often than you’d like.

 

[orwelldesign]

Having had a google account arbitrarily suspended, then having to deal with google's support to try and figure out why ... there is no way I am putting all of my authentication eggs into google's basket.

Same same. I lost access to my first.last Gmail after going through four phone numbers in a year, then lost access to the backup email. So no more first.last.

That's a giant pain in the ass. If Google had a "user services" department, I'd be much more tempted. But... since Google users aren't Google customers, there's really no reason for them to entertain spinning up such a department.

 

[Jarrex]

So then, Dan, how about an article showcasing those options?



I think pushing people to use passkeys without a detailed understanding of exactly how they are better to use than passwords, along with pushing while the environment is still being developed, gets you exactly the kind of pushback you're seeing in this thread.

Exactly.

Nobody can respond with any kind of workflow diagram or white paper show-casing that all the criticism is invalid. People are just responding saying it's invalid without anything to actually back it up.

Most people aren't going to uproot their entire digital process on a whim without actually understanding it.

 

[dangoodin]

Edit: Also, for a primer this document is kinda missing a simple explanation of what passkeys actually are and how they operate!

Fair enough. I just updated to the post to add:

From Apple:

Passkeys are built on the WebAuthentication (or "WebAuthn") standard, which uses public key cryptography. During account registration, the operating system creates a unique cryptographic key pair to associate with an account for the app or website. These keys are generated by the device, securely and uniquely, for every account.

One of these keys is public, and is stored on the server. This public key is not a secret. The other key is private, and is what is needed to actually sign in. The server never learns what the private key is. On Apple devices with Touch ID or Face ID available, they can be used to authorize use of the passkey, which then authenticates the user to the app or website. No shared secret is transmitted, and the server does not need to protect the public key. This makes passkeys very strong, easy to use credentials that are highly phishing-resistant. And platform vendors have worked together within the FIDO Alliance to make sure that passkey implementations are compatible cross-platform and can work on as many devices as possible.

The FIDO specs require that whatever syncing mechanism a user elects (be it from Apple, Microsoft, Google, or a third party) it provide end-to-end encryption the way iCloud Keychain and password syncing currently do. This means that the private key is unknown to the cloud provider. They private key resides on the device and can only be accessed by unlocking the device using either a unlock PIN, a fingerprint or face scan.

 

[Deleted member 440187]

I understand that fingerprints and face scans are supposed to never leave the device. But how is this enforced? Is just us trusting a hardware manufacturer to adhere to a standard or are there physical barriers to this?

I used to think webcam "on" indicators we actually in line serially with the webcam so that any power to the webcam would necessarily turn on the indicator. Later it was revealed that they were separate and so a bad actor could turn on the web cam without the indicator being on.

So is it the case that fingerprints, etc, definitely don't leave the device or that they don't leave the device as long as now and forever in the future the makers of hardware choose to make that the case?

 

[Deleted member 853683]

Ars alone has published 5 Passkeys are killing passwords articles in 7 months. Three of which are in the last week. That's not just covering new tech stuff, that's pushing a narrative. Look at the non-tech sites saying "Google and Apple are killing passwords!" It's been going on for the last 1-2 months pretty constantly on the same websites.

Not only that but every single article lacks actually talking about the tech aspects -- which is easily seen by the fact that nobody actually can point to a diagram and say for sure "yup this is how it works". Bluetooth required? Yes? No? Who knows. Even you say it yourself that they are all saying it's ready for primetime.

If it's not ready for primetime, why are sites like ars pushing it like it is? Why is it on this perpetual news cycle with nothing new about it. There isn't any new details about it yet here we are, talking about it again.

I only see two articles from Ars in the past week (one was the same story renamed, but shows up twice in the search results).

View attachment 55642

The first is a news story about how Google now supports passkeys by Ron, and the second is a deep dive by Dan. This type of coverage is pretty common from Ars - a shorter news story covering a new product, feature or press release, and then a more in-depth story a few days later that goes into details, sometimes by a different editor who may have a different focus.

I can't speak to every other tech site you read, but companies put out press releases and updates all the time, and so you will see coverage hit from multiple sites at around the same time. Sites also want to maximize the amount of mileage they get out of any one topic, so they will often post multiple stories for the same news beat. I don't think this is evidence of a vast conspiracy to dupe everyone into giving up control over their digital security, or Ars being on the take from big tech, or whatever.

This model of tech news coverage happens for literally everything, so if this worries you, then fair enough. But it's not like coverage of passkeys is too different from any other product or service related tech news.

 

[Schpyder]

Also Google passkeys ARE ALREADY cross platform. My Google passkeys are currently being synced not just by Google, but also through the iCloud Keychain and Windows Hello. As you note, Bitwarden, 1Password and a bunch of other third parties will soon also provide syncing.

Well, let's be absolutely clear here. If you've generated passkeys on Android so they can be synced through the Android ecosystem, and then use the QR code dance to log in on iOS, those specific Android passkeys are not being shared and synced cross-platform, what you've done is create another passkey for the iOS/Mac ecosystem. So in the regard of the individual, actual public/private keypair, no, those are ecosystem-specific. But what a lot of people aren't getting is that you can have multiple passkeys for a single account, and once setup on an ecosystem, then those keypairs are ecosystem-wide (assuming the ecosystem does end-to-end encryption, like you state above). This is a bit unweildy in initial setup until you've got keypairs set for all your software platforms, and I think why a lot of people are waiting for a platform-agnostic sync system before jumping on board.

 

[Beyond Opinion]

Maybe not for you but my fingertips also regularly wear out from hand work, even when I wear gloves as much as possible. It’s basically inevitable.

Sorry but your flex of “my fingers are more scuffed than yours” is silly

Oh, I am fully aware that I have soft, child-like hands from a career as a software developer. I was just trying to point out that for some people, fingerprint unlock isn't an issue. The examples I gave were the worst case scenarios that I encounter.

 

[dangoodin]

Why limit your (dis-)trust to a hardware vendor? Do you have any reason to believe Microsoft won't nuke your account without clear cause or form of recourse? Sorry for the Google translate-link: horrorstory

I agree with your roll-your-own open source route, without dependencies on external parties.

Can you explain how passkeys make it easier from Microsoft et al. to "nuke your account"? Even if these companies could delete the passkey from your device, what exactly would stop you from simply logging in with your password the way you always used to?

 

[dangoodin]

I imagine all the desktop Windows computers used in businesses and government would need a whole lot of Bluetooth dongles to implement this.

Nope. There are other ways to access your account. Yubi keys are just one example.

 

[Carewolf]

Exactly. This only benefits the 99.9% of the population that doesn't follow good password practices. For the rest of us, it is just a hassle.

If the overide is a password it is not an improvement for the rest either.