Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Bringing passkeys to Android and Chrome

android-developers.googleblog.com

Post reply on HN
Print view View original

211–220 of 264 posts

Re: Bringing passkeys to Android and Chrome

#211

Post by pabs3 »

account-5 wrote: post #36

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…

You could use virtual-fido to store the keys on your computer, potentially in your password manager. Theres a link in my other comment about it.

Re: Bringing passkeys to Android and Chrome

#212

Post by pabs3 »

KronisLV wrote: post #67
account-5 wrote: post #36

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 don't use my phone to log in to anything. All my stuff is done on a computer with a password manager. More or less the same, except that I haven't found good TOTP solutions for the desktop, to the tune of KeePass (something that can run on Windows/*nix instead of making me use something like FreeOTP, Google Authenticator or other Android/iOS apps; or in addition to the mobile apps). That said, even with multiple…

I do TOTP on desktop Linux with Firefox, browserpass and pass.

https://github.com/browserpass https://www.passwordstore.org/

Re: Bringing passkeys to Android and Chrome

#213

Post by webmobdev »

yupper32 wrote: post #57
webmobdev wrote: post #49

Earlier quoted context omitted.

This is also going to be a body blow for our privacy - if BigTech have access to your keys, so will the government and both can abuse it. The idea is to force you to "save password on device" (whether you want to or not) so that when a government authority gets your device they can also easily access all your internet accounts. US courts have already affirmed that it is legal for the police to force you to unlock you…

Why would this be different than any other password manager in that aspect?

Online service don't force me to use to use password managers.

Re: Bringing passkeys to Android and Chrome

#214

Post by rzimmerman »

stavros wrote: post #171

The thread here seems like a dumpster fire to me. Everyone here is worrying about lock-in to an open standard, so I want to clarify things. WebAuthn is an open standard. It's a way for you to prove to a website that you have a specific private key. There's no lock-in, because the key is portable (unless you don't want it to be). There's no privacy issue, because the key is unique per website. There's no security issu…

I'm also surprised at how negative the reaction here is to Google embracing an open standard. Both Android and iOS devices keep your passwords/keys encrypted end-to-end between your devices. You can absolutely share passkeys between devices (if you want to) and even make them exportable to another secrets manager (if you want to).

If you ask me what's one thing in 2030 people will look back on and say "I can't believe we did that!" I'd have to say "passwords". Passwords need to die and WebAuthn is a great step forward.

Re: Bringing passkeys to Android and Chrome

#215

Post by webmobdev »

jackson1442 wrote: post #82
webmobdev wrote: post #32

Earlier quoted context omitted.

And BigTech's cloud (who will have no problem sharing it with the authorities). And when all your keys are on the device, it also becomes a lot easier for the government to access all your internet accounts by getting access to the device.

They're end-to-end encrypted. Did you read the article? This is the same threat model as password managers, which are generally approved of on HN.

Who cares if it is "end-to-end encrypted" if the device with all your keys / credentials can be easily used to access all your online accounts? (And no online service forces me to use a password manager).

Re: Bringing passkeys to Android and Chrome

#216

Post by scott00 »

wnevets wrote: post #91
mooreds wrote: post #76

Earlier quoted context omitted.

My understanding of passkeys is that they are using WebAuthn under the hood (hence the nod to the w3c/FIDO at the end, and the fact that the passkey in the screenshot was associated with tribank.us). They are solving a very real problem. WebAuthn uses private keys, but those private keys are tied to the device where they were created. This is a blessing and a curse. It's a blessing because it eliminates a whole trove…

> They are solving a very real problem. WebAuthn uses private keys, but those private keys are tied to the device where they were created. To clarify I am not talking about the issue of syncing the device's private key. I am talking about the artificial problem these walled gardens are creating by having every single domain getting its own randomly generated private key. The only practical way to keep all of these ra…

In most implementations there's only a key or two on the device that you have to sync. The webauthn protocol requires a site that accepts it to store a small amount of arbitrary data for each registered device, which is then handed to any device that attempts auth. Most devices use that to store a copy of the site-specific private key encrypted with one of the device keys. (IIRC there's usually a symmetric key and an asymmetric keypair that are protected by the device, and the symmetric one is the more convenient to use for encrypting the site data.)

It's possible to store every key the device has registered, but most devices don't do it that way to keep the cost of the secure enclave low.

Re: Bringing passkeys to Android and Chrome

#217

Post by skybrian »

throwaway41597 wrote: post #148
skybrian wrote: post #125

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…

The lock-in is very real and relevant. Websites already have a hard time to get users to sign up, so requiring them to enroll backup authenticators (which they won't have) is not going to work. Printing or writing down backup codes is even worse from a UX point of view. IIRC the spec has a flag to hint that the passkey is backed up (in iCloud or your Google account) so the relying party (website) knows whether backup…

That's a good point, but on the other hand, this "lock in" doesn't seem worse from how Chrome generates and saves passwords now?

It would be ideal to set up backup auth before you need it, but you could also do it when you decide to move off Google.

So, not really a lock. It's a vulnerability, though, if you lose access to the Google account for some reason.

Re: Bringing passkeys to Android and Chrome

#218

Post by Ferret7446 »

Someone1234 wrote: post #69
cglong wrote: post #54

People are raising really good points here, but I do find it interesting how negatively this news is being received vs. when Apple said the same thing: https://news.ycombinator.com/item?id=31643917

The second most popular top level comment chain is: > Unless I can back it up and import it into a new device from a competitor, then there is no way I am going to use this unless forced. I do not trust one company anymore. Which is the same sentiment as this thread. The first comment was just talking about the open standard of Apple's implementation and weakness of 2FA loss/recovery. https://news.ycombinator.com/ite…

I find that sentiment ironic because I won't use it unless it can't be backed up (the main selling point of 2FA and hardware keys).

If it can be backed up, then a casual bystander/process can also "back up", filch all of your credentials in a few moments with you being none the wiser.

The protocol is open, so I can use one proprietary key from company A, one from company B, and a few open source keys. Keep one for regular use and the rest as backups.

Re: Bringing passkeys to Android and Chrome

#219

Post by olliej »

olliej wrote: post #159
throwaway41597 wrote: post #150

Earlier quoted context omitted.

> No, because PBKDFs are not a good mechanism for creating encryption keys I'm curious about what you mean by this. Isn't it in part what PBKDFs are designed for?

sowbug has a more detailed answer, but the TLDR is the PBKDFs were consider ok a long time ago before the security implications were really understood. Essentially they're low entropy in practice (e.g. a person _could_ make a 10+ word password, but they're not going to for a password they have to enter frequently). You're much better off using the password to a truly random key, though that of course immediately rais…

"using the password to a truly random key"

should be

"using the password to gate access to a truly random key"

Re: Bringing passkeys to Android and Chrome

#220

Post by tjoff »

potatoz2 wrote: post #189
tjoff wrote: post #147

Earlier quoted context omitted.

> If you lose one you have one safely secured that can get you into any service you need to. Even that is not good enough, by a longshot. This is so much worse than even regular passwords. It works for corporatiosn. Lost your key? Go to IT and generate a new one. It does not work for individuals.

If you don’t trust yourself to have backup keys, you use the Google or Apple ecosystem. As long as you can get back into your Google or iCloud account, you can get back into every other passkey-protected website. You can also use third-party “cloud” password managers if you prefer. WebAuthn lets you dial the convenience/security tradeoff exactly however you prefer. I’ll be using hardware tokens, but I’ll be telling n…

It's not that I don't trust myself to have backup keys it is that the workflow is completely broken.

You have to manually add each key on every service. And you can typically at best only add two keys.

It is not a working system for individuals.

Post reply on HN