Live data from Hacker News

Bringing passkeys to Android and Chrome

android-developers.googleblog.com

161–170 of 264 posts

Re: Bringing passkeys to Android and Chrome

#161
post #73

I don't use my phone to log in to anything. All my stuff is done on a computer with a password manager. At no time am I even likely to rely on Google for anything this important; every other week there's a thread about Google killing off accounts for no reason. No way would any sane person allow Google access to this with their track record. And this isn't even considering my suspicion that Google only wants to "help…

I’m with you, I de-Googled all my services a few years ago, and I couldn’t be happier with the decision. I’m curious though, what’s preventing you from using a password manager on your phone? I use KeePass, and I’m able to use my password DB on any device I want.

How do you handle syncing? I use KeePassXC on my desktop, and I back up the encrypted password DB to SpiderOak, but I haven't figured out a good way to get that DB onto my phone, auto-synced.

Also are you worried about the security of the DB on your phone? My password DB's passphrase is a good 50+ characters long, which I can type quickly on my laptop, but I can't imagine pecking that out on a phone. And I feel like I would not want the DB unencrypted/unlocked all the time on my phone; given the possibility of my losing it or it getting stolen, I'd want it to re-lock immediately after each use.

Re: Bringing passkeys to Android and Chrome

#162

I don't use my phone to log in to anything. All my stuff is done on a computer with a password manager. At no time am I even likely to rely on Google for anything this important; every other week there's a thread about Google killing off accounts for no reason. No way would any sane person allow Google access to this with their track record. And this isn't even considering my suspicion that Google only wants to "help…

Why can't the password manager kill your account? I am not advocating for google, just asking about the other solution you are relying on.

I don't think the point is that they can't. Just far more unlikely to, and there's usually more recourse. Google is mega-corp who never listens to their users, and are un-contactable. Some AI can and probably will ban some people for no real reason and even Google won't know why it happened.

Re: Bringing passkeys to Android and Chrome

#163

Do you know if it's possible to see a list of stored passkeys in Android? I installed the Play Service beta, managed to create a passkey and sign in, but can't see the list of credentials anywhere in the UI.

There will be, in the password manager settings on Android (under Settings, "Passwords & Accounts" and "Google"), but it will unfortunately take a couple of more days to roll that out to the beta.

Re: Bringing passkeys to Android and Chrome

#164

Earlier quoted context omitted.

Seems like you wouldn't want to share passkeys for the same reasons you don't normally want to share passwords? Instead, each website that accepts passkeys should allow you to register multiple devices and probably print out backup codes as well (for the especially important accounts). If there's no reason to migrate anything then lock-in is irrelevant. Just add more login methods so that when you lose some, you have…

I have over 500 online accounts. Imagine if all of them used a login method where I had to have backup devices registered, instead of just me backing up the credentials (like I do today with a password manager). With backup devices, whenever I upgrade or replace a device, I need to go to each of the 500+ online accounts and register the new device. This is much more work than a quick login to each site via my passwor…

Yeah, this is why I connect unimportant accounts to Google or GitHub, and use two step auth only for the important ones.

Re: Bringing passkeys to Android and Chrome

#165

Earlier quoted context omitted.

Apple, on the other hand, has terrible problems with working with others that google does not. Apple will happily tell you that if you want grandma to have a whatever color text bubble, you should buy her an iPhone, to name a recent example, rather than adopt the standard everyone else is using. I bought a Macbook last holiday season and couldn't even set it up until my wife set up her iPhone on my account to activat…

> I bought a Macbook last holiday season and couldn't even set it up until my wife set up her iPhone on my account... I have no idea what you mean by this. You do not need, and have never needed, to own an iPhone to use an Apple computer. > I bought my wife a iWatch last week and briefly thought of getting myself one but you can't use it without an iPhone... This, on the other hand, makes a little more sense. The App…

W/o the phone, the watch is a… watch.

If pre-installed and configure, it’s still convenient for things like wallet/Apple Pay, esp when I do dumb stuff like forget my wallet and phone at home and need to pay for things.

Re: Bringing passkeys to Android and Chrome

#166
I'm noticing very little discussion about the user aspect, and I say that with non-savvy users in mind. I run a mid-sized web app/community where I've been supporting such users for a long time.

Right now, I offer a classic login, and a few social providers. You'd think this is straightforward to support, but about 70% of support requests consists of the endless ways in which users can mess this up.

"Can't get in"

Try recover password. Email didn't come. Because they entered the wrong email. Correct email this time. No wait, think I signed up with a social account, not sure which one, have many. Login worked. Wait now it doesn't again (saved browser password did not update).

This is just the tip of the iceberg. This new solution, whatever merit it has, is going to be additive. It won't replace anything, it's yet another way to log in, if at all, as it depends on websites implementing it and about 90% of the web is basically not maintained.

So it's only adding complexity/confusion specifically to these users, which I consider to be the vast majority. In turn leading to more support headaches.

Re: Bringing passkeys to Android and Chrome

#167

Earlier quoted context omitted.

It would mean that somewhere there is a common root, which if extracted, can derive all keys for all sites. Why introduce such a risk when there’s no reason to do that?

If I can get access to your device to exfiltrate the private key that generates the domain specific keys, why wouldn't I also have access to the the randomly generated site keys? Your device needs access to the keys to use them. In both cases your device has a private key that it needs to secure. In my scenario we remove the third party cloud service.

I can register an authenticator multiple times, for instance to represent multiple different accounts of my own, or represent multiple people on a shared device.

If I delete a credential, the expectation is that registering a new credential is not going to correlate the authenticator (and thus the user).

If I want to have hygiene steps of rotating the cryptographic key a user uses to log in, I won't want registration to create the same key pair each registration.

And for the cloud sync:

The UX can present that web authentication is an option to log in. The user will be confused if that option is presented for sites which will not recognize the authenticator.

The site can store data alongside a credential to be returned to optimize the log in process, such as a site-specified identifier to look up the user credential in a database. That state needs to be synchronized.

Re: Bringing passkeys to Android and Chrome

#168

Earlier quoted context omitted.

> I am talking about the artificial problem these walled gardens are creating by having every single domain getting its own randomly generated private key. That’s part of the design though. That’s what completely eliminates the ability to do phishing-attacks. If there were a common root to leak, that would just provide a new target for phishing attacks, and effectively risk reducing a persons entire online security d…

> That’s part of the design though. That’s what completely eliminates the ability to do phishing-attacks. If the actual domain name is used to generate the key that would also completely eliminates the ability to do phishing-attacks. Paypal.com and PaypaI.com would generate two completely different keys.

That's how hardware FIDO2 keys work now. There's no walled garden. You can remember a passphrase that generates a key that is used to derive every website's key in turn.

No cloud, no synching, nothing. You're fucked if your passphrase is stolen, but that's the tradeoff.

Re: Bringing passkeys to Android and Chrome

#169

Earlier quoted context omitted.

Seems like you wouldn't want to share passkeys for the same reasons you don't normally want to share passwords? Instead, each website that accepts passkeys should allow you to register multiple devices and probably print out backup codes as well (for the especially important accounts). If there's no reason to migrate anything then lock-in is irrelevant. Just add more login methods so that when you lose some, you have…

I have over 500 online accounts. Imagine if all of them used a login method where I had to have backup devices registered, instead of just me backing up the credentials (like I do today with a password manager). With backup devices, whenever I upgrade or replace a device, I need to go to each of the 500+ online accounts and register the new device. This is much more work than a quick login to each site via my passwor…

WebAuthn credentials can be backed up, if you want. They can also be impossible to back up (and thus steal), if you want. It's up to you, which is more than I can say about passwords.

Re: Bringing passkeys to Android and Chrome

#170
post #40
post #27

Passkeys sound like another way for companies like Google and Apple to lock you into their walled garden. Having each walled garden randomly generating a key for every single domain instead of using the actual domain name as part of the key is a great way to lock regular people into their respective ecosystems.

The entire third party auth push has turned into what may be one of the largest incumbent power grabs I have ever seen. Stuff like Google Amp or even App Store walled gardens pale in comparison. What drives me nuts is how little discussion of this I've seen. People don't even seem aware of the implications of it. It's being pushed hard as a boon to security, which it is in some cases, but at a cost that nobody is eve…

Man, every one of these comments has completely misunderstood the point. WebAuthn is an open standard. The provider is only there to sync your key. If you want, you can keep it yourself.

Why is everyone yelling about the sky falling down when this is the best thing to happen to authentication since ever?

Post reply on HN