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

41–50 of 264 posts

Re: Bringing passkeys to Android and Chrome

#41

Post by hcurtiss »

numbsafari wrote: post #33
toomuchtodo wrote: post #26

Earlier quoted context omitted.

Yes, definitely. USPS + Login.gov could act as trust anchors, with cryptographic keys reprovisioned upon proofing, versus storing them. I am open to whatever is the optimal balance between security and practicality. https://www.uspsoig.gov/document/role-postal-service-identit... > The Postal Service Reform Act of 2022 has recently expanded the Postal Service’s ability to provide identity verification to all levels of…

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…

I can assure you that a lot more constituencies than just the Christian coalittion are concerned about universal government-issued IDs as passports for online participation.

Re: Bringing passkeys to Android and Chrome

#42

Post by LibertyBeta »

selykg wrote: post #12
LibertyBeta wrote: post #5

Interesting. I'm still struggling to see how this is better than just using a yubi/solo-key

I would use this in addition to those. Instead of having to buy two Yubikeys I can buy one and use a software solution as well. Since I already use a phone capable of doing the same thing, let my phone be my main authenticator, and then I can use a Yubikey as a backup. It's not like one is necessarily better than the other, except that you already carry a phone and they're capable of being a hardware device that work…

That makes sense. I do worry we are starting to build key chains that are leveraged obliquely to the user.

Once passkey support comes to bitwarden I'll be a little more comfortable I think.

Re: Bringing passkeys to Android and Chrome

#43

Post by waynesonfire »

sowbug wrote: post #16
jasonjayr wrote: post #7

And what happens if your Google account that these keys are tied to is locked/revoked for a nebulous ToS violation?

From TFA (the security blog): "The main ingredient of a passkey is a cryptographic private key. In most cases, this private key lives only on the user's own devices, such as laptops or mobile phones."

so what? maybe it is also pinned to your google account so regardless that it's a private key that only lives on your device, doesn't at all mean you can somehow transfer it. it could simply be one of many components that make up the effective key.

Re: Bringing passkeys to Android and Chrome

#44

Post by tialaramex »

toomuchtodo wrote: post #18
sowbug wrote: post #16

Earlier quoted context omitted.

From TFA (the security blog): "The main ingredient of a passkey is a cryptographic private key. In most cases, this private key lives only on the user's own devices, such as laptops or mobile phones."

Final step is key escrow authority that will store your private key and produce it to you if you can proof your identity with government ID. It is not enough to store in cloud storage (which Google, Apple, or someone else could deny you access to), or your own device you could lose or destroy (which is why backup hardware tokens are always recommended for U2F MFA); you need the ability (but not a requirement) to bind…

For the vast majority of services, there's no value or even negative value in binding my "identity" to some sort of government ID.

You accept Google and Apple might deny you access but then you just blithely assume the US Federal Government (for example) would never do so, which shouldn't pass the laugh test.

I can imagine it being valuable if my government wants to help get me back in to, say, my bank accounts if I somehow lost all my credentials (e.g. my home burned down suddenly but I somehow escaped with nothing). But I don't feel like my GitHub, Gmail, Patreon, etc. make sense in this context. If my friends can lose a phone every year or two and make a new god-damn account, I think "My home burned down and I have nothing" is a good enough reason.

Gitlab's attitude of (for unpaid accounts): Too bad, just make another one - seems appropriate for almost everything. If tialaramex never wrote another HN comment, and instead tlrmx or tialaramex2 or whatever began posting, who would even care ?

Re: Bringing passkeys to Android and Chrome

#45

Post by dane-pgp »

selykg wrote: post #15
greatgib wrote: post #10

Another product that they will use their dominant position to force down our throat!

This is all part of the FIDO Alliance, so, a standards based solution that anyone with the wherewithal to implement it can do so. Many password managers have already said they'll be supporting it, as well as major vendors (Google and Apple for instance). I'm struggling to see your complaint being a valid one. This is basically webauthn, so use a Yubikey or similar device if you wish.

When you say "the FIDO Alliance", you mean the entity that runs a Metadata Service[0] which:

> provides organizations deploying FIDO Authentication with a centralized and trusted source of information about FIDO authenticators.

The aim of this centralized system is to allow revocation of hardware that doesn't meet their unchallengeable opinion of whether you've spent enough money on your device or not. They can similarly require that devices do biometric scanning[1], and be issued by your government, and require you to agree to lengthy (and self-updating) terms of use.

There are actually (at least) two different types of device attestation that FIDO support[2]. One uses a hardcoded on-device private key, that's common between 100,000 devices of the same model, which means that an attacker can brick 99,999 other people's devices just by extracting the key from their own device. The other method requires a certificate from a "trusted third-party Attestation CA", which presumably allows a malicious (perhaps government-mandated) CA to spy on (and filter) every login request you make.

This system is like a dystopian parody of the traditional model of web security, which had no need for "authenticators that have a Trusted Platform Module (TPM) onboard", and which only required CAs to be on a list that the user agent is in control of (and users can add their own CAs to). Instead, what FIDO are building is basically DRM for human identity, with all the corruption and failure modes that entails.

[0] https://fidoalliance.org/metadata/

[1] https://fidoalliance.org/specs/biometric/requirements/

[2] https://research.kudelskisecurity.com/2020/02/12/fido2-deep-...

Re: Bringing passkeys to Android and Chrome

#46

Post by toomuchtodo »

tialaramex wrote: post #44
toomuchtodo wrote: post #18

Earlier quoted context omitted.

Final step is key escrow authority that will store your private key and produce it to you if you can proof your identity with government ID. It is not enough to store in cloud storage (which Google, Apple, or someone else could deny you access to), or your own device you could lose or destroy (which is why backup hardware tokens are always recommended for U2F MFA); you need the ability (but not a requirement) to bind…

For the vast majority of services, there's no value or even negative value in binding my "identity" to some sort of government ID. You accept Google and Apple might deny you access but then you just blithely assume the US Federal Government (for example) would never do so, which shouldn't pass the laugh test. I can imagine it being valuable if my government wants to help get me back in to, say, my bank accounts if I…

HN participants, for whatever reason, approach these challenges as “but this isn’t a problem I have.” You’re the builder (broad strokes and wild assumption), but there are far more citizens (hundreds of millions at least) who are simply consumers of these systems. They are your grandparents, your parents, your siblings, your children. Passkeys are rolling out internet wide to all sorts of critical services people rely on, and they’ll need a solution if they lose their cryptographic identity assertion, because you can’t always just create a new account when you lose access (either because data, finance, or authority is tied to that account). Loss of gitlab access is inconsequential compared to losing access to your email, your bank account, etc.

Re: Bringing passkeys to Android and Chrome

#47

Post by mindslight »

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 sentiment about remote software and storage. It's just that individual autonomy loses out over time due to convenience created by the massive investment in the surveillance economy.

Re: Bringing passkeys to Android and Chrome

#48

Post by jrm4 »

jackson1442 wrote: post #21
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…

it is your key, it lives on your device (and is synced across devices using your cloud account if you so choose)

It's a nanny-ish third-party in the middle. That increases convenience, but also greatly increases your threat surface.

Re: Bringing passkeys to Android and Chrome

#49

Post by webmobdev »

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.

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 your device if it is biometric protected (fingerprint or face scan etc.). Moreover, by forcing you to use your personal device for identity verification, BigTech is ensuring that identifying you and datamining your personal data becomes more easy for them. Don't be surprised if this is also extended in the future as a "super cookie" service to allow easy tracking.

Re: Bringing passkeys to Android and Chrome

#50

Post by colordrops »

selykg wrote: post #3
colordrops wrote: post #2

Ugh, I hope they don't make it difficult to use third party password managers. I'm pretty happy with vault warden.

Pretty sure there's been talk on the Bitwarden community forums about them adopting support for using it as a provider. I assume once that's available you might start to see it move into Vaultwarden. But, that's sort of the risk you run with using a 3rd party to a 3rd party...

At least with Vaultwarden, it's open source and running locally with data stored on a server in my house, so if they misbehave, I could easily fork or switch projects. If Android doesn't allow or otherwise hobbles 3rd party password managers, there isn't much recourse.
Post reply on HN