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

101–110 of 264 posts

Re: Bringing passkeys to Android and Chrome

#101

Post by saulrh »

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…

Bitwarden will do TOTP, and its CLI tool is quite usable. If you want it fully local, just stand up a docker of their server software (which is open source) or the open source reimplementation (vaultwarden).

Re: Bringing passkeys to Android and Chrome

#102

Post by josteink »

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…

> 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 down to 1 shared root-key.

While obviously better than having just 1 common shared password, why reintroduce this risk when you don’t have to?

Re: Bringing passkeys to Android and Chrome

#103

Post by yakak »

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…

Every site is supposed to be keeping its randomly generated data to give back to you as an input to proving you have the device, but no one wants to give the relying parties open source "enterprise authentication" for free like in the days when Apache was king..

I don't really see a safe way to do what fido was trying to do while letting keys flow about and using their cloud for the original setup with the security we were originally expecting wouldn't have the conveniences they are talking about.. So it seems like more phishing, now for getting an activated device/chrome session.

Re: Bringing passkeys to Android and Chrome

#104

Post by josteink »

saulrh wrote: post #101
KronisLV wrote: post #67

Earlier quoted context omitted.

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

Bitwarden will do TOTP, and its CLI tool is quite usable. If you want it fully local, just stand up a docker of their server software (which is open source) or the open source reimplementation (vaultwarden).

> Bitwarden will do TOTP

Not disputing this, but it requires a “pro” account which is $10 a year.

No big deal to me, in fact I find it a great deal, but I think it’s fair to be clear about this as not to provide false expectations.

Re: Bringing passkeys to Android and Chrome

#105

Post by politelemon »

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…

> but I can at least visualize Apple having the scale to do that.

> Google on the other hand has a horrendous reputation for

Neither are true nor false but definitely exaggerations. All you're doing is displaying personal biases by providing them with benefit-of-the-doubts. They too have a reputation for locking people out, and are well known for turning data over, but one that HN in gernal prefers to ignore.

Re: Bringing passkeys to Android and Chrome

#106

Post by wnevets »

josteink wrote: post #102
wnevets wrote: post #91

Earlier quoted context omitted.

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

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

Re: Bringing passkeys to Android and Chrome

#107

Post by josteink »

wnevets wrote: post #106
josteink wrote: post #102

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.

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?

Re: Bringing passkeys to Android and Chrome

#108

Post by joshuamorton »

jrm4 wrote: post #96
joshuamorton wrote: post #90

Earlier quoted context omitted.

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…

But again, what is the unique risk here? Google shutters and your phone bricks simultaneously, and you're left unable to log in?

Like this is lower risk than a local password manager or a yubikey or... Because it's both local and cloud backup. Be precise, what is the risk?

Re: Bringing passkeys to Android and Chrome

#109

Post by politelemon »

joshuamorton wrote: post #85
jrm4 wrote: post #48

Earlier quoted context omitted.

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

Be precise: what threat is added here that is added by a third party holding encrypted keys? Like this isn't particularly different from me backing up my (encrypted) disk which contains my (further encrypted) keys to the cloud somewhere.

In the second instance, you are controlling the where and how of your keys being backed up. If you are smart you will have backed up your keys to multiple locations, for disaster recovery. One of the fundamentals of privacy is having control of your data, which the first option does not provide.

Re: Bringing passkeys to Android and Chrome

#110

Post by linsomniac »

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…

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 activate the laptop. I bought my wife a iWatch last week and briefly thought of getting myself one but you can't use it without an iPhone (they have a "kids" feature where a parent can activate it but it basically has no smarts at that point AFAIK).

So, for making an authentication standard, I'd trust Google over Apple.

Post reply on HN