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

151–160 of 264 posts

Re: Bringing passkeys to Android and Chrome

#151

Post by SAI_Peregrinus »

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…

KeePassXC supports TOTP. Right-click a key, TOTP→Set Up TOTP... and put in the secret key (and settings if needed).

Re: Bringing passkeys to Android and Chrome

#152

Post by dickhardt »

api wrote: post #40
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.

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…

I founded Hellō to address your concerns. Check out the Show HN post I wrote this morning. https://news.ycombinator.com/item?id=33177705#33182379

Re: Bringing passkeys to Android and Chrome

#153

Post by dickhardt »

Q: how many of you will add support to Passkeys to your application? Is it worth the effort of adding yet-another-way-to-login for your users? It will be a long time before you could use it as the ONLY way to login. You will need to figure out how to enable your existing users to convert to Passkeys. Apple has a glide path for converting username password -> but not for other mechanisms.

I believe we in letting the user choose whatever way is best for them to login -- and to take that burden off of the developer. If you want to learn more, check out the Show HN post on Hellō I wrote this morning. https://news.ycombinator.com/item?id=33177705#33182379

Re: Bringing passkeys to Android and Chrome

#154

Post by dickhardt »

jjnoakes wrote: post #132
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…

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…

I founded Hellō to solve this problem. A neutral service where you get to choose how to login, and how you can recover your Hellō Wallet. Done.

See Show HN post I wrote this morning https://news.ycombinator.com/item?id=33178285

Re: Bringing passkeys to Android and Chrome

#155

Post by smoldesu »

vangelis wrote: post #149
smoldesu wrote: post #134

Earlier quoted context omitted.

Apple absolutely did not abandon the Xserve platform after promising a professional and modern Unix experience. Google is definitely the only one with a penchant for mercy-killing unsuccessful products.

Google isn't killing the horse with a broken leg. It's killing anything less than the triple crown winner.

If your horse cost $150 million/year, you'd probably be itching to kill it too.

Re: Bringing passkeys to Android and Chrome

#156

Post by [deleted] »

olliej wrote: post #142
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…

> Are the keys encrypted with a key derived from a master password? No, because PBKDFs are not a good mechanism for creating encryption keys. Instead you have an actual random key, and your devices gate access to that key with your device password. > Does the decryption only occur on the user's device? Yes, because only the user's devices have access to the key material needed to decrypt. Apple cannot decrypt them. >…

[deleted]

Re: Bringing passkeys to Android and Chrome

#157

Post by sowbug »

throwaway41597 wrote: post #150
olliej wrote: post #142

Earlier quoted context omitted.

> Are the keys encrypted with a key derived from a master password? No, because PBKDFs are not a good mechanism for creating encryption keys. Instead you have an actual random key, and your devices gate access to that key with your device password. > Does the decryption only occur on the user's device? Yes, because only the user's devices have access to the key material needed to decrypt. Apple cannot decrypt them. >…

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

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

Password-based key derivation functions start with the assumption that some entropy is provided by the user. Which means that the entropy is typically of awful quality. A PBKDF does the best it can with that low entropy, which is to make it into a time- and maybe space-expensive brute-forcing problem. But a PBKDF is starting with one hand tied behind its back if the user-supplied entropy is "password" or "hunter2." If we aren't burdened by that assumption, then we can generate high-quality entropy -- like 128 or 256 bits of CSRNG-generated noise -- and merely associate it with the user, rather than basing it on the user's human-scale memory.

PBKDFs also generally assume that users are transmitting their plaintext passphrases to the server, e.g., when you HTTP POST your credentials to server.com. Of course, browsers and apps use transport security so that MITMs can't grab the passphrase over the wire, but the server actually does receive the phrase "hunter2" at some point if that's your passphrase. So again, it's a rotten assumption -- basically the foundation of most password-database compromises on the internet -- and PBKDF does the best it can.

If you remove that assumption and design a true asymmetric-encryption-based authentication system, then you don't need the obfuscation rounds of a PBKDF because the asymmetric-encryption algorithm is already resistant to brute-forcing. The script kiddie who steals /etc/passwd from a server would effectively obtain a list of public keys rather than salted hashes, and if they can generate private keys from public keys, then they are already very wealthy because they broke TLS and most Bitcoin wallets.

Think of passkeys as a very user-friendly client-side certificate infrastructure. You wouldn't let your sysadmin base your enterprise website's TLS certificates on a private key derived from their dog's birthday. You wouldn't let users do that for their certs, either.

Re: Bringing passkeys to Android and Chrome

#158

Post by zie »

ezfe wrote: post #13
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?

At least on iOS, passkeys are stored locally in Keychain, even if they're also synced over iCloud (when enabled).

In my experience on iOS, you can't make Passkeys work without also turning on syncing, that's sort of the entire point of Passkeys, otherwise they would just be WebAuthN tokens.

Re: Bringing passkeys to Android and Chrome

#159

Post by olliej »

throwaway41597 wrote: post #150
olliej wrote: post #142

Earlier quoted context omitted.

> Are the keys encrypted with a key derived from a master password? No, because PBKDFs are not a good mechanism for creating encryption keys. Instead you have an actual random key, and your devices gate access to that key with your device password. > Does the decryption only occur on the user's device? Yes, because only the user's devices have access to the key material needed to decrypt. Apple cannot decrypt them. >…

> 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 raises the question of how you store the true key :D Modern systems use some kind of HSM to protect the true keys, and if they're super integrated like the SEP (or possibly the SE, I can never recall which is which) on apple hardware they can simply never expose the actual keys and only provide handles and have the HSM encrypt and decrypt data directly before it's seen by the AP.

Re: Bringing passkeys to Android and Chrome

#160

Post by yalogin »

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…

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.
Post reply on HN