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...

 

[Jarrex]

Update: it has been answered!



I'd like to apologize to Dan, but I also want to make him aware that there might be something funky with Ars's CDN or whatever manages serving your articles, because this change didn't show up for me through multiple forced refreshes, closed and new tabs, until about 5 minutes ago. I was very confused by your insistence that you had updated the article when the text never changed!

Using a password should not be the answer to something meant to replace passwords.

 

[plectrum]

There is a lot of confusion here, I think because an entire tech stack has been dumped on us and presented as a fait accompli. Let me, as an ignoramus, try to deconstruct it by analogy with what I do understand: SSH key pairs. I invite others to pick holes in what I get wrong.

1. Public/private authentication keys. This works roughly the same as SSH. The website only knows your public key, and you sign messages to prove you hold the private key.

2. Anti phishing protection. Keys are specific to a site, so a phishing site gets a different key. SSH has host keys for this, I assume keypass uses something to do with TLS host keys? Your browser uses that to select which key to use? Or just by DNS name?

3. Means of unlocking the keys to prove the right user is using them. SSH has passphrases, I assume this is where the biometric / Bluetooth thing comes in? SSH can also unlock keys with smartcards, and so I assume the biometric is a bit like another unlock mode?

4. Syncing keys between devices. This is presumably where cloud ‘ecosystems’ come in, like iCloud and Chrome password sync? For SSH there’s no support, but you can cook up your own with rsync or whatever?

What did I get wrong?

If the above is broadly right, I could imagine building an open stack that basically does the same as SSH does using a pile of files in ~/.ssh and rsync to move between devices. That is the ‘bicycle’ approach where all the moving parts are exposed and easy to understand what’s going on.

 

[Spudster]

Once again, a very handy feature not available to Google Workspace accounts until .

As time moves on, it has become harder and harder for me to find value in Workspace.

 

[dangoodin]

Once again, a very handy feature not available to Google Workspace accounts until .

As time moves on, it has become harder and harder for me to find value in Workspace.

Support for Workspace will be coming sooner rather than later. It won't be long.

 

[Schpyder]

Using a password should not be the answer to something meant to replace passwords.

This is kind of ridiculous. How else would you authenticate to an existing service in order to update your authentication mechanism? Aside from the already-discussed QR-and-bluetooth method. And while the attack surface on the server side isn't necessarily reduced by enabling rather than requiring passkey login, it significantly reduces the attack surface client-side, as you're strictly engaging in a key exchange, enabled by OS-level authentication. And that's a win for everyone.

If you're to the point that you can't trust any of your OS's security features, you might as well just throw your computing devices away and go live on a tropical island or something. At some point some level of trust has to be given to some bit of software.

 

[fvgfvghvgv]

Wouldn't this mean that web sites could lock out anonymous browsing?

My understanding of HTTPS is that it acts on the fly, to secure the data transfer between my browser and the web server. However, a passkey would be uniquely associated with my device, so any gain in security would be (theoretically, at least) offset by a loss in privacy.

Or am I misunderstanding?

You’re misunderstanding the comment you’re replying to and I think you overlooked the word ‘analogy’.

mariotrevi essentially said: ‘I hope that these two very different uses of public key cryptography become equally ubiquitous some day in the future’ - not that authentication (passkeys or any other form of authentication) would somehow be added to the secure transport later (HTTPS).

 

[randomcat]

You mean all those hacked, cracked and released databases that were acquired by phishing, which this prevents?

Man, it feels like the literal peanut gallery here.

They were not all acquired by phishing. Phishing is an actual, specific thing, it is not synonymous with "hacking" in general no matter how often someone tries to use it that way.

This does not prevent your password from being compromised. A password can be compromised without you ever using it, if the backend is compromised, and they are all the time. If a password exists on an account, attackers can use it to blow right past the passkey.

The only way this would increase security is if passwords were abolished. But if they were, this system wouldn't work for the many reasons people have already pointed out. It really is like Bitcoin's relationship with actual money--BC only works if real money exists, but real money existing also makes it pointless to jump through all of BC's unnecessary, non-value-adding hoops.

 

[Jarrex]

This is kind of ridiculous. How else would you authenticate to an existing service in order to update your authentication mechanism? Aside from the already-discussed QR-and-bluetooth method. And while the attack surface on the server side isn't necessarily reduced by enabling rather than requiring passkey login, it significantly reduces the attack surface client-side, as you're strictly engaging in a key exchange, enabled by OS-level authentication. And that's a win for everyone.

If you're to the point that you can't trust any of your OS's security features, you might as well just throw your computing devices away and go live on a tropical island or something. At some point some level of trust has to be given to some bit of software.

I am saying long-term. If passkeys are to "kill passwords" saying that the way to add non-bluetooth devices as authenticated passkey devices is to "use a password" you are effectively still with the same weakest link - passwords.

This does not reduce client-side attacks, because if you can effectively gain passkey access via a password, then it's the same as a password.

 

[Joklers]

I don't understand. If you don't trust Google you must not have an account with them, and obviously this post isn't for you. But for readers who do use Google using a passkey to log in vs. a password gives Google no more control than it already has.

Using Google because my phone requires I have a Gmail and trusting Google with the authentication methods for the rest of the services I use in my life is a completely different question.

I honestly don't know how someone who is supposed to be in the field of security can bring such black and white thinking to this. Trust is not a binary, the principle of least privilege is a foundational principle?

 

[fvgfvghvgv]

I can, but I know you can work this out yourself. Also I am in no way inclined to help you with this because frankly I really dislike you.

You made an accusation that you could not back up…

‘I claimed that you’re a bad person and I have lots of evidence that you’re a bad person, but when I’m asked to show the evidence I go all quiet suddenly’.

Standard response when concern trolls get called out, everywhere in the internet.

 

[Schpyder]

I am saying long-term. If passkeys are to "kill passwords" saying that the way to add non-bluetooth devices as authenticated passkey devices is to "use a password" you are effectively still with the same weakest link - passwords.

This does not reduce client-side attacks, because if you can effectively gain passkey access via a password, then it's the same as a password.

This is, frankly, atemporal nonsense that ignores the inconvenient fact of the linear flow of time.

IF someone switches to using passkeys to login to a site, THEN, going forward, client-side attacks meant to harvest passwords will be stymied. Your contention rests upon the password in question already being compromised, at which point the account is already compromised. Just because passkeys won't ex post facto remediate compromised passwords doesn't deprive them of any security utility.

 

[Joklers]

Wait, how does turning on passkeys cause people to "uproot their entire digital process"? Once you save a passkey, you are 100% able to continue logging in with a password exactly as you have done in the past. This comment is a prime example of what I mean about criticisms being based on fundamental misunderstandings.

I'm not the one misunderstanding anything. You are deliberately ignoring the larger implications and design questions that people have brought up repeatedly because...I don't actually know. You seem really personally invested in people using passkeys, to the point of ignoring sincere questions, glossing over serious concerns, and being insulting when we point out things you haven't clarified.

This article has very clear problems, and your response to questions is so blatantly biased and often in bad faith that I'm pretty startled.

 

[Jarrex]

This is, frankly, atemporal nonsense that ignores the inconvenient fact of the linear flow of time.

IF someone switches to using passkeys to login to a site, THEN, going forward, client-side attacks meant to harvest passwords will be stymied. Your contention rests upon the password in question already being compromised, at which point the account is already compromised. Just because passkeys won't ex post facto remediate compromised passwords doesn't deprive them of any security utility.

you are working under the presumption that if databases can’t be breached then passwords can not be hacked.

Just because people will not store their passwords on the server side does not improve client side security any more than proper hashing and salting of said passwords.

 

[Schpyder]

you are working under the presumption that if databases can’t be breached then passwords can not be hacked.

Just because people will not store their passwords on the server side does not improve client side security any more than proper hashing and salting of said passwords.

This is a level of infosec apocalyptic defeatism with which I'm not willing to engage, sorry.

 

[fvgfvghvgv]

Using Google because my phone requires I have a Gmail and trusting Google with the authentication methods for the rest of my life is a completely different question.

I honestly don't know how someone who is supposed to be in the field of security can bring such black and white thinking to this. Trust is not a binary, the principle of least privilege is a foundational principle?

Black and white thinking - for example “Using Google because my phone requires I have a Gmail and trusting Google with the authentication methods for the rest of my life”.

So you have an android phone and you don’t save ANY passwords or 2FA credentials on the device? And if you don’t trust Google surely it’s vastly better to store a passkey than a password on your android device…

How are you managing your credentials for all your online accounts and services if you refuse to save any passwords or 2FA on your android device?? Easily memorised passwords, password re-use, paper notepad etc? Passkeys are significantly more secure than all of those and they are impossible for Google to steal from you.

 

[Alexandria77]

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 here. Even the thought of trusting Google with my Pass_____s scares the crap out me. I'm still needing to set aside some time to decide if I stick with an online PW manager (and I use WebAuth as my 2FA) or switch solely to a self-hosted PW database. But that's a different topic.

 

[alastairmayer]

I don't understand. If you don't trust Google you must not have an account with them, and obviously this post isn't for you. But for readers who do use Google using a passkey to log in vs. a password gives Google no more control than it already has.

Then you are suffering a failure of imagination.

Of course I have a Google account. Several of them, if you count different gmail accounts separately. That doesn't mean I trust Google, only that I trust them a little bit. I also have my own email domain and server.

It's not just about "giving Google more control," it's about trusting them not to fuck up a process they're already making more complicated than necessary. Their history in this regard (including just abandoning projects they lose interest in) is less than admirable. I'm also not forgetting that Google is an advertising company, and that I'm their product, not their customer.

 

[dudeimlost]

Can you give an example or two of my comments that were "highly entertaining" and "convey[ed] disturbing lack of temperament"?

lemme see here... I think the string to and from BasP is a good example of where you could have stopped well ahead of #382's '...stop responding to my posts.' There is also the defense of the well above average count of promoted comments or all caps response would fall in that line as well.

As you may respond to my 'examples,' I will state that this is strictly IMHO and you'd be best to save your pen for defending more noble clauses rather than defending yourself from opinion of one minor (and not even subscribing!) commenter. At some point, tho, some comment(er)s have troll like tendencies. which should be dealt with by non-engagement. for another example, the forehead/chin bezel jokes don't get responses from Ron at this point... I get it (only partially, since I didn't write this piece), it's frustrating. Please remember plenty here also appreciate authors such as yourself who follow up and respond to commenters.

 

[Jarrex]

This is a level of infosec apocalyptic defeatism with which I'm not willing to engage, sorry.

It’s not defeatism. This doesn’t improve security if passwords are a fallback. It’s very simple. The strength of authentication is only as good as the weakest link. People that don’t use MFA for password based auth still won’t use MFA for passkey auth. Which means that password fallback is the same as just having a password login. Congrats, we’re back to square one with regular users.

 

[Joklers]

I caught one instance of me brushing off someone simply asking a question, and I apologized for it. It's possible I did it elsewhere, and if I did I'll apologize for that, too. My impatience came from people asserting complete misinformation with so much conviction and then getting 90+ upvotes. That kind of thing just misleads people wading in to the comments trying to understand stuff.

Here you go:

...
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.

You're the article author, you're the one supposed to be doing the research and providing us with answers. Why would we come to Ars to get told to do our own research? That's your job, and reacting defensively when people have questions is wildly unprofessional. Your job is to provide information, not tell us to find our own answers.

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

You're bad faith reading and contradicting yourself. Only having to go through this long process doesn't mean a person doesn't have to go through the process. The objection that this is a long, complicated process isn't actually addressed by saying 'you only have to do it once per device per account'.

It sounds like you don't understand how asymmetric encryption works. ICloud Keychain syncs the public key. It never sees or touches the private key.

That's just straight up insulting.

You don't have to trust the big three to use passkeys. By all means, keep using passwords, but please inform yourself before commenting.

This is classic 'do ur own research' forum troll behavior. This is the point where I honestly started questioning what on earth you and Ars leadership in general were thinking.

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

You're supposed to know what you're talking about with computer security. You really ought to know that trust is not a binary, that people need to use the tools that will get the job done and compromises happen, and that still doesn't mean that using a system we don't fully trust for various tasks is different from storing authentication methods for other services in that system.

I could go on, but the rest is very much in the same vein. People brought genuine questions and concerns, both with passkeys and with this specific article, to this comment thread and you responded by getting defensive and belligerent.

Also, I don't see responses to people saying this seems like huge tech support lift, I don't see responses to people asking why large corporations are pushing for this or discussing the broader implications. It all adds up to you seeming incredibly dismissive of actual questions and cherrypicking what you respond to.

 

[adamsc]

Had it ever crossed your mind that people making incorrect statements may simply have misunderstood the technology and therefore think that they are correct?

I’d be more sympathetic to this point if it wasn’t mostly the same few people repeating the same talking points on every article and refusing to do even basic research. The biometrics ones are tedious because it shows they’ve done no research whatsoever on how those systems have been designed since the turn of the century, and also not read any of the previous comments earlier in the thread or, in several notable cases, replies to them personally but still feel like they’re contributing something spamming the same incorrect assertions.

The difference is easy to tell. People who are trying to learn say things like “I don’t know how revocation works with biometrics” or “how is this not risky?” rather than confidently asserting that something they just made up invalidates the whole concept. When you’re talking about something which most of the top security people in the world are recommending, it’s smart to assume that there isn’t some blindingly obvious flaw which you noticed in the first 5 seconds but none of the hundreds of people who worked on it ever did.

 

[Joklers]

Black and white thinking - for example “Using Google because my phone requires I have a Gmail and trusting Google with the authentication methods for the rest of my life”.

So you have an android phone and you don’t save ANY passwords or 2FA credentials on the device? And if you don’t trust Google surely it’s vastly better to store a passkey than a password on your android device…

How are you managing your credentials for all your online accounts and services if you refuse to save any passwords or 2FA on your android device?? Easily memorised passwords, password re-use, paper notepad etc? Passkeys are significantly more secure than all of those and they are impossible for Google to steal from you.

There are password managers which don't rely on Google services. Using a password manager app is not the same thing as using Google as a password manager, or trusting Google to handle authentication.

 

[dagar9]

I remember when Ars was a technology website. Now it seems way too many of its readers are luddites

With the Luddites, the issue wasn't so much the tech as its impact. The Luddites were home-based weavers. Introduction of steam weaving machines operated by children in factories promised to destroy their livelihoods. Think the intro of robots or AI, and how they may enable some employers to fire most of their workers.

Though here I think the issue is that the tech has not been clearly explained. And maybe can't be, since it's complex, incomplete and seems to be implemented differently in different places. Like all things, it will have pros and cons, and the cons are fully as important as the pros.

 

[Secondfloor]

They were not all acquired by phishing. Phishing is an actual, specific thing, it is not synonymous with "hacking" in general no matter how often someone tries to use it that way.

This does not prevent your password from being compromised. A password can be compromised without you ever using it, if the backend is compromised, and they are all the time. If a password exists on an account, attackers can use it to blow right past the passkey.

The only way this would increase security is if passwords were abolished. But if they were, this system wouldn't work for the many reasons people have already pointed out. It really is like Bitcoin's relationship with actual money--BC only works if real money exists, but real money existing also makes it pointless to jump through all of BC's unnecessary, non-value-adding hoops.

Looking for these backends that are compromised all the time, I’m sure you can provide citations, right?

Or don’t I’ll probably have you on ignore anyway. Less noise to distract from the conversations of the people that know what they are talking about.

 

[alastairmayer]

Yubikeys are great. If people could review oxygen on the internet you'd find bad reviews of it.

Oxygen is horrible stuff. It's the major cause of fires, for example, and rust.

 

[davmac1962]

Linux does not support storing or managing passkeys yet. However, I was able to use the QR code with my Android phone and its passkey to login to a GMail account from my Gentoo Linux laptop. At first it did not work at all. But then I realized that the bluetooth daemon was not running on my Linux laptop. So I started the bluetooth daemon and then I paired my Android phone with my Linux laptop. After that, logging into GMail from Chrome on my Linux box worked great using a passkey stored on my Android phone.

 

[BasP]

You made an accusation that you could not back up…

‘I claimed that you’re a bad person and I have lots of evidence that you’re a bad person, but when I’m asked to show the evidence I go all quiet suddenly’.

Standard response when concern trolls get called out, everywhere in the internet.

I’ve pointed out plenty in earlier posts. Dan’s standard response now seems to be “please point out where I said X” and it’s a tiresome game I’m unwilling to play. If you think I’m trolling when both myself and other commenters here have pointed out instances of his poor behaviour many times already, then you’re wrong but I’m not going to spend any more energy to try and convince you.

 

[dangoodin]

Using Google because my phone requires I have a Gmail and trusting Google with the authentication methods for the rest of my life is a completely different question.

If you're logging in to Google with a password, you are already placing huge trust in Google authentication. Passkeys require no more or less trust than what you already are placing in Google. Google account passkeys aren't "authentication methods for the rest of your life." You can use your password anytime you like, and you can delete the passkey any time you want.

 

[Secondfloor]

With the Luddites, the issue wasn't so much the tech as its impact. The Luddites were home-based weavers. Introduction of steam weaving machines operated by children in factories promised to destroy their livelihoods. Think the intro of robots or AI, and how they may enable some employers to fire most of their workers.

Though here I think the issue is that the tech has not been clearly explained. And maybe can't be, since it's complex, incomplete and seems to be implemented differently in different places. Like all things, it will have pros and cons, and the cons are fully as important as the pros.

It’s a W3C standard. I’m not sure the documentation could be any more complete for anyone that wanted to learn more.

Very similar to the people that ask questions in the comments of articles that are answered in the linked citations. People are so lazy they won’t click on a link, let alone spend 10 minutes educating themselves.

 

[Jarrex]

Looking for these backends that are compromised all the time, I’m sure you can provide citations, right?

Or don’t I’ll probably have you on ignore anyway. Less noise to distract from the conversations of the people that know what they are talking about.

Random cat isn’t wrong. If passwords are a backup for passkeys - then passwords are still being stored in a database, which means that the issue that passkeys are to solve (not using passwords) doesn’t improve server side storage of passswords, because it’s still happened. And it doesn’t improve client side because you can still use passwords for the same thing as a passkey.

 

[alastairmayer]

No one will ever support passkeys for login in lieu of a password. Support for passkey logins is in addition to passwords. There's a big difference.

That's a mighty bold prediction. Just like ssh will always allow login via password in addition to ssh keys. Oh, wait, the admin can turn that off, for your own protection to increase security.

 

[Joklers]

If you're logging in to Google with a password, you are already placing huge trust in Google authentication. Passkeys require no more or less trust than what you already are placing in Google. Google account passkeys aren't "authentication methods for the rest of your life." You can use your password anytime you like, and you can delete the passkey any time you want.

You're still really giving the impression that you're deliberately misreading what I say.

Logging into a service with a password is not at all the same thing as trusting the company providing that one service to reliably handle authenticating me to other services. There genuinely has been a lot of work on the different levels of trust involved here. Discussions of federated identity are good place to start.

 

[Joklers]

Can you help out the Ars management by pointing out all these "blatantly biased" comments made in bad faith. I have decided to challenge the many, many, many inaccurate assertions being made in this thread. And in a halndful of cases, I have done so using the same vehemence used in asserting the misinformation. I keep asking people for examples. So far no one has provided any.

This comment is honestly funny, because I did actually provide some examples of some earlier inappropriate comments, directly quoting you, in this forum thread.

At this point you are genuinely behaving exactly like someone trying to start a forum fight.

 

[dangoodin]

Same here. Even the thought of trusting Google with my Pass_____s scares the crap out me. I'm still needing to set aside some time to decide if I stick with an online PW manager (and I use WebAuth as my 2FA) or switch solely to a self-hosted PW database. But that's a different topic.

OK, this is the kind of thing I'm talking about. We have been around and around and around this issue of trusting Google with your passkey. Have you read through the comments already? You will find multiple instances explaining why you don't have to trust Google with your passkey. You will find multiple instances explaining that using Google account passkeys places the same level of trust in Google -- neither more nor less -- than you place already when logging in to Google with a passkey.

This is tedious. I'm happy to explain things to people who ask questions. But asserting the kind of nonsense in this comment with such a high degree of certainty is very different than asking questions. When they come over and over and over despite me and other people explaining fundamental misunderstanding . . . well, it's easy to grow impatient.

 

[chronoss2022]

the issue here isnt that its not good tech to use its that google is still a 3rd party doing it where by ME the user cant say without certainty that they dont have a back door that cant someway be exploited in some fashion
and cause its done by them i cant verify authenticity in first place

this is a non trusted system that is saying trust me
if google wanted to give that trust it would create software we could use and then it can get audited

 

[Joklers]

That's a mighty bold prediction. Just like ssh will always allow login via password in addition to ssh keys. Oh, wait, the admin can turn that off, for your own protection to increase security.

Right? The idea that sure, we can just trust that corporations will keep supporting passwords too even though all of their rhetoric is saying that passkeys are going to kill passwords and getting rid of passwords shifts liability to users saving the corporation a lot of liability and customer support expense is inexplicably naive. They've said out loud that they want to get rid of passwords.

That Dan is refusing to engage with this idea is strange. It seems like a fascinating intersection of law and security technology.

 

[dangoodin]

Then you are suffering a failure of imagination.

Of course I have a Google account. Several of them, if you count different gmail accounts separately. That doesn't mean I trust Google, only that I trust them a little bit. I also have my own email domain and server.

It's not just about "giving Google more control," it's about trusting them not to fuck up a process they're already making more complicated than necessary. Their history in this regard (including just abandoning projects they lose interest in) is less than admirable. I'm also not forgetting that Google is an advertising company, and that I'm their product, not their customer.

How is trusting Google not to fuck up the passkey process, which is an industry standard more of a stretch than trusting Google not to fuck up its own proprietary method for password authentication?