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

91–100 of 264 posts

Re: Bringing passkeys to Android and Chrome

#91

Post by wnevets »

mooreds wrote: post #76
wnevets wrote: 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.

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 randomly generated keys synced across multiple devices is to use the "cloud".

If instead the per site key was generated using a private key and the domain name, users would only need to transport that one private key to another device and would get syncing for free without the requirement of the "cloud".

Re: Bringing passkeys to Android and Chrome

#92

Post by ivanhoe »

collegeburner wrote: post #35
numbsafari wrote: post #33

Earlier quoted context omitted.

Except that here in the US a non-trivial number of politicians of a particular persuasion[1] actually believe that government issued ID, of any kind, is the "mark of the beast". There's a reason that Real ID had a lot of push back. Having USPS, already a political bogey-man for that same crowd, become a holder of "identity" is probably going to face a lot of pushback. [1] just one, recent example... https://www.al.co…

because simple, easy-to-use ID lowers the barrier for demanding ID in more places and attacking anonymity. the easier we make it to demand id, the more people will demand it. wanna use a fake name/not divulge your identity? doing something politically sensitive where you may need some protection? just like your privacy? tough shit show your id or GTFO.

Shouldn't we instead solve the problem that you might "need some protection" because you're doing something political - instead of relying on security-through-obscurity which honestly doesn't even really work anymore, IDs or no IDs. There's so many other ways for governments to track people of interest these days.

Re: Bringing passkeys to Android and Chrome

#93

Post by TheNewsIsHere »

quadrifoliate wrote: post #75
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

It's not particularly surprising. Apple has a much better reputation at customer service than Google does – they have actual stores you can walk into. Now I'm not sure whether they can help you unlock your Apple ID if you prove to them that you're the owner of the account, but I can at least visualize Apple having the scale to do that. Google on the other hand has a horrendous reputation for locking out people out of…

At the risk of being pedantic, no. Apple Stores aren’t able or empowered to provide Apple ID support beyond what the public website based recovery workflows provide. I am sure someone will note that someone at an Apple Store has helped them reset an Apple ID password. What I mean is that Apple Store employees have neither procedure nor access to override Apple’s account system. You have to call support for assistance beyond what the website can do. I am sure Apple Store employees have been helpful and I’m sure policies have changed over time.

As an Apple user I find this as frustrating as it is wise. Mostly for future-me who may one day not be as savvy and manage to screw myself.

I don’t fully trust iCloud Keychain and Apple to never lose my data in a “I don’t concern myself with backups” manner. So I opt for using Passkeys where I can also add my FIDO2 tokens.

Re: Bringing passkeys to Android and Chrome

#94

Post by Ciantic »

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…

Depending on your setup you could just generate TOTPs on command line and copy to clipboard, that's what I've implemented: https://github.com/Ciantic/totper

It works pretty well with pass (password manager) that stores each individual entry in GPG encrypted file. GPG is pain, but if you happen to use it already then it works.

Re: Bringing passkeys to Android and Chrome

#95

Post by tgsovlerkhgsel »

joshuamorton wrote: post #83
mixedCase wrote: post #38

Earlier quoted context omitted.

Are the keys encrypted with a key derived from a master password? Does the decryption only occur on the user's device? Is this master password not reused for the account or has account authentication been changed to use a cryptographic proof produced on-device? If the key is ever decrypted on vendor's servers, everything else is theater. And this is all of course also excluding auto-updating vendor-supplied authentic…

tl;dr: Yes, and further they're only decrypted using the secure chip on the device, so the vendor supplied authentication firmware can't be updated without user interaction/approval. From a post linked in the article: > Passkeys in the Google Password Manager are always end-to-end encrypted: When a passkey is backed up, its private key is uploaded only in its encrypted form using an encryption key that is only access…

The question I always ask to figure out how things work: What happens if I lose my phone?

Vendors trying to peddle a solution will always try to answer this question in a way that doesn't say "well in that case you're screwed" and any answer except "you're screwed" means there is some kind of potentially-vulnerable recovery process, and the description of how the process works usually gives you an idea of how secure it is (or at least a starting point to ask more questions).

Re: Bringing passkeys to Android and Chrome

#96

Post by jrm4 »

joshuamorton wrote: post #90
jrm4 wrote: post #86

Earlier quoted context omitted.

I don't know, and you don't either, because I'm willing to bet that "Google" is smarter than both of us. That's kind of the point. We have to trust that Google won't mess things up and we have essentially no recourse if they do.

I'm unclear on what you think they could do. Is your idea here that Google is so smart that they can break end to end encryption? If so, we've got bigger problems. It isn't fair to presume that everyone shares your lack of knowlege on a subject, and it's simply incorrect to presume that because you don't understand something that it cannot be safe or reliable.

What they say today about end-to-end encryption seems like it should work fine from a technical point of view. It is entirely possible the Google is very good about this, and when implemented, it might work perfectly as stated today.

But I'm not talking about incorrect or correct and I don't care about fairness in presuming whoever's intelligence either, because the thing I'm talking about is more important, which is risk.

Large companies taking on big tasks that you don't pay them for is undeniably risky for many reasons. One, they screw it up today. Two, they don't screw it up today but they change it tomorrow. We know this because many of these companies have done things like this before.

Re: Bringing passkeys to Android and Chrome

#97

Post by jrm4 »

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.

Yeah, I think HN is mostly wrong about those as well. :)

Re: Bringing passkeys to Android and Chrome

#98

Post by jrm4 »

mindslight wrote: post #47
jrm4 wrote: post #8

Nah. For all the talk of "one app to rule them all" (which is an awful idea) this is a step closer to that. For all it's faults, crypto has one thing right -- not your keys, not your stuff. I get that doing keys/passwords is hard, but the best thing in the long run is for them to stay in the hands of the user. And if not, the holder of the keys needs to be someone you can easily hold accountable, i.e. either fire, or…

> For all it's faults, crypto has one thing right -- not your keys, not your stuff Erm, this isn't really an aspect of cryptocurrency, per se. It's more of a general rule that informed the initial thinking around cryptocurrency. In fact, most users of cryptocurrency seem quite content to give up cryptographic custodianship. If you went back a similar time to the nascent web/cloud/etc, you'd find plenty of similar sen…

That's a fair point, in that I should have said something like "crypto-fundamentalists." But the idea is the one I wanted to get across, and I have mostly those same feelings about remote software and storage (e.g. I tell students, priority one in your life -- if there's something digital you care about, e.g. photos, get at least one copy of them on something you can hold in your hand)

Re: Bringing passkeys to Android and Chrome

#99

Post by pGuitar »

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

Apple isn't any better then Google... they are just better at hiding it.

Re: Bringing passkeys to Android and Chrome

#100

Post by josteink »

mooreds wrote: post #76
wnevets wrote: 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.

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…

> it's a curse because the same person logging in from their ipad, android phone, and desktop PC needs to set up WebAuthn three times.

Or just get some Yubikeys.

Post reply on HN