Hacker News Reader

Comment by NikolaNovak | Hacker News Reader

I don't understood this. I keep not understanding this.

What's my basic authentication method to a site or system I can write down, backup, export or memorize? What happens if I go naked to a friend and want to use their devices to access my systems? What happens if I lose one or more of my existing devices? What happens if I get locked out of one or more of my devices? Basically am I the only one who doesn't think phone is my life and I don't want my life to be over if I lose my phone?

I feel like I'm in a twilight zone of phone dependencies. Already so many systems refuse to let me in if I don't have my phone with me due to sms 2fa I didn't ask for, even though I have dozen other devices and valid credentials. Now we just want to stop pretending and just lock me in to phone forever? My phone goes with me everywhere I go and is super likely to get lose broken or stolen. I don't want it to be a dependency to my online access.

View on HN

I'm in the process of migrating to a new phone. My old phone had an eSIM that was tied to some 2FA (not by choice, and it couldn't be changed, because security), and my temp phone doesn't support an eSIM, so until the new one arrives I can't access some services. You don't even need to lose anything to be locked out.

Did you not keep any of the backup code? I am not sure why 2FA is related to the eSIM unless you mean certain services force using SMS as the method to receive 2FA. I have experienced that same restriction with financial services in the US. I agree, it's frustrating and feels counterproductive to security because it could motivate someone to borrow a friend's device temporarily to access the services. eSIMs are even more annoying as there is a limited amount of times you can switch devices.

It is the very rare site or service that actually refuses to let you back in with an email confirmation or something. Sites with SMS 2FA / mobile app 2FA will nearly 100% of the time let you fall back to email.

And why not? It's a huge support burden to do otherwise. You can say "we told you that you'd be locked out" and not even confirm to the user that an account exists with that user ID, but then half of the users who get locked out will complain about it on social media.

You can only really enforce 2FA if your site has to do with money or similar.

For major sites, FAMG having access to email is not enough in my experience. I was recently locked out of my Instagram account and lost my 2FA. Instagram required me to contact support from a known previously associated email, but on top of that I had to upload a picture of myself holding a piece of paper with a handwritten nonce and they checked against my previously uploaded pictures. I also had to wait a period of time before they would telling me what nonce to use and starting the verification process.

I have heard stories of people not being let in and having to contact friends who work at Facebook and have access to the internal support queue. I know my friend had to do something similar at Google and have a friend make a internal support ticket when they were locked out of a gmail account. That experience with Instagram is the reason I moved away from using DUO for everything to Aegis where I can copy a password encrypted backup of my 2FA secret keys like I would any file. I am grateful I learned that lesson by losing 2FA to a single account.

> What's my basic authentication method to a site or system I can write down, backup, export or memorize?

There isn't one. This is by design. Logging into your bank or email provider will in the future require mobile device shenanigans that are either proprietary or so complex and opaque that you have no chance of "controlling" anything, or even really understanding what's actually going on.

The main lobby driving this forward consists of Google, Apple, and Microsoft. This should tell you all you need to know.

Which part of passkeys / Webauthn / FIDO requires a mobile device?

In principle, none. In practice, many websites will check the user agent and flat out refuse service unless it's one of a pre-approved list of implementations, regardless of whether it would work or not.

This has been happening for a long, long time already, for many browser features, and such "standards" pushed forward by the major mobile vendors will only make the problem worse.

Well if we're making up things that websites haven't done yet then yeah I'm angry too.

Unless you're using one of the proprietary desktop OSes then you have to use one of the proprietary mobile OSes.

https://developers.google.com/identity/passkeys/supported-en...

Assuming desktop Chrome doesn’t support third party password managers like 1Password and Lastpass that are similarly part of the FIDO alliance.

Passkeys aren’t a Chrome feature they’re a Webauthn feature. So if Chrome doesn’t provide the features you want on your platform you should be able to use another browser / password manager combo that does.

No you do not need to use anything proprietary to use WebAuthn. There are open source software[0] and hardware keys[1].

[0]: https://github.com/psanford/tpm-fido

[1]: https://solokeys.com/

WebAuthn supports attestation of key storage and site owners might choose not to trust keys coming from an unknown DIY device.

Fortunately that feature isn't used outside of enterprise environments. Apple's passkeys don't support it so there will not be any mainstream adoption for requiring an attestation cert.

What part of WebAuthn, a W3C standard, is "proprietary or [...] complex and opaque"?

The FIDO alliance also consists of far more companies than just "Google, Apple, and Microsoft", although they're certainly members. https://fidoalliance.org/members/

> What part of WebAuthn, a W3C standard, is "proprietary or [...] complex and opaque"?

Ask Mozilla. FIDO U2F is so complicated that Firefox support was hidden behind a config flag for a long time, then "a hard-coded permission for Google Accounts"[1] was implemented in order to not fall too far behind Chrome.

The linked email thread is an eye-opener on how many intricacies and unresolved questions there are, with multiple mentions of non-standard behavior implemented in the Google ecosystem, undermining WebAuthn. This is how such "standards" work in practice, and passkeys will be no exception.

[1] https://groups.google.com/g/mozilla.dev.platform/c/q5cj38hGT...

FIDO U2F is not WebAuthn, and if you had even bothered to skim the link you provided, you probably would have realized that considering:

- they go out of their way to explicitly differentiate them, and

- the entire discussion is about U2F and bringing in support for it in a limited sense so that people adopt WebAuthn instead of U2F.

Like, did you even read the link you provided?

So, again, what about WebAuthn is proprietary or complicated?

I'm not claiming they're the same. What matters is that U2F is what many websites implemented, which is why those problems arose in the first place.

This time, websites will implement "Chrome passkeys", which will be almost-but-not-quite WebAuthn, just like Internet Explorer's box model was almost-but-not-quite CSS.

If there are only two or three major players and the standard is sufficiently complex, "standard" becomes synonymous with "what iOS and Android do".

But to answer your question:

> So, again, what about WebAuthn is proprietary or complicated?

The WebAuthn standard is 184 pages of A4 size. That's a technical document, the length of a typical novel. Are you seriously asking what's "complicated" about that?

U2F has nothing to do with WebAuthn. You bringing it up is literal whataboutism. We aren’t talking about it, we are talking about a completely different technology.

What about WebAuthn, explicitly, is complicated for you to understand? What about it is not a web standard that can be implemented in many different ways?

Furthermore, HTTP 1.1 is 174 pages, yet Firefox was able to implement it. Standards are, generally speaking, technical documents. Because that is what guarantees interoperability, that thing you are so vehemently defending.

Chrome passkeys are WebAuthn. Period. Fin. End of story. There is no separate implementation, they are the same thing. It is a standard that anyone can implement on either side that is inter compatible with whatever implementation is used. What part of this do you not understand?

I think they think that Google/Apple/Microsoft are deliberately creating dense standards so that nobody else has the technical means to implement them. The evidence presented was that one of these (U2F?) took a long time for Firefox to implement. Just a little note to dispel all this BS in one swoop: Firefox was the first browser to implement WebAuthn. https://blog.mozilla.org/blog/2018/05/09/firefox-gets-down-t...

> It is a standard that anyone can implement

WebAuthn supports attestation of a key storage device. How are you going to persuade site owners to trust your self-signed attestation certificate?

Ask the folks over at SoloKeys, who are both open source and FIDO certified.

It also supports it. Whether it’s enforced is a site owner’s decision, as are the trusted roots they use.

If a site owner wants to limit to only a single type of authenticator, they can already do that by only trusting its key, so I don’t see how that’s relevant to the topic of implementing the standard.

it's certainly complex!

https://webauthn.guide/ challenge, attestation, rp, alg -7!? usb, ble, nfc!? it seems very easy to "hold it wrong" :)

and if you add u2f-fido to the mix, which is how most people so far saw webauthn in practice, it's even more complex.

it took me a lot of time to figure out what actually happens when I tap the security key. do I have one keypair? no, actually I have a lot, one for each site, but the site stores it in a clever encrypted encoded scheme.

Do you use SSH keys?

This is SSH keys for signing into websites.

Which, yes, means you need at least one device in your possession containing your private keys.

1Password has already announced support for storing and syncing passkeys. Apple and Google also allow you to sync them via your account.

Nothing ties it specifically to your phone compared to any of your other devices or an online account/vault that you store your keys in.

I can print out my SSH key and store it in a safe, or freely copy it between systems. All of these services are intended to prevent that by using on device secure enclave functionality and the like - it puts control the keys out of my reach.

But you should be able to use your own password manager that can export them if you choose. I could be wrong but I don't think the standard requires that the keys are stored out of user reach.

> I could be wrong but I don't think the standard requires that the keys are stored out of user reach.

It really doesn't matter what the standard requires when the most popular implementations belong to companies like Google or Apple, they will get to decide how it works.

So you think Google and Apple will block third party password managers from providing passkeys to the browser?

Yes, I do.

That's strange and would be a pretty big about-face.

Apple, the most locked-down and proprietary OS vendor, has great support for third party password managers in their OSes and has been improving that support in recent years.

If they kick 1Password etc. out of the Mac/iOS ecosystem that would be a pretty big deal. It could happen, but why would they do so?

That would be strange, given that Passkeys are just Webauthn tokens synchronized across devices. I don't know of a single application that only supports one vendor of Webauthn token, and I don't see that changing soon.

Not quite, but close. They'll convince website owners that for "security reasons", they should refuse passkeys that came from third-party password managers or anything else open source, and instead only accept ones that came from something remotely attestable to be theirs.

Then why bother with Webauthn and the FIDO alliance instead of just making this part of Sign in with Apple / Sign in with Google? That seems easier for Apple and Google if their plan is to be the only sign-in providers.

Ever heard of "embrace, extend, extinguish"?

Let me get this straight. . . You think Google will provide hooks for password managers in Chrome and Android, and then “convince” website owners, presumably via super bowl ads or something, to detect and filter out passkeys coming from the password managers they did the work to enable?

Google convinces website owners of things all the time. Remember how AMP became popular because otherwise Google lowered your website's ranking?

Standards like WebAuthn support attestation of a key storage, so the site can see who has manufactured it and can choose not to trust weird DIY or open source solutions without an attestation certificate.

The way I interpret it, the worry is that something happens that allows Google, Apple, Microsoft, or some other password aggregator to take advantage of a perfect storm event (whether real or manufactured surreptitiously).

An example situation that comes to mind most easily would be some password aggregator having passwords stolen without realizing it. Let's assume that there's some backdoor or vulnerability in at least one system that allows bulk downloading of unencrypted username/password pairs and contact information. Then let's say a kid gets hold of that and thinks it might be funny to bulk send everyone's passwords to all of their contacts.

The password aggregator that has a truck driven through its security hole hopefully looses business. But then Google, Apple, Microsoft, etc., say something to the effect of...

"See? You really can't trust *anyone* but us. We are truly perfect and without any more truck holes of course. If people really wanted independent 2-factor authentication, they would have used it! Lots of people didn't, and look what happened. We need to save people from themselves!"

...Then the hooks come out.

> This is SSH keys for signing into websites.

No it's not. It's a shackle that will tie users to two or three platform providers (Google, Apple, and Microsoft) because websites will refuse to interoperate with implementations that aren't from those.

"Your browser is currently unsupported. To log in to your Amazing Bank account, open this website on your Android or iOS phone and place your finger on the home button."

Just because the underlying cryptographic primitives are similar to SSH, doesn't mean this will work anything like SSH in practice.

So websites will have whitelisted platform support instead of using the Webauthn / FIDO standard that Google, Apple, Microsoft, 1Password, and others are supporting?

They'll be using the standard AND whitelisting browsers. Just like some WebRTC-based services used to tell you "your browser is unsupported" when opened in Firefox, but spoofing the user agent to look like Chrome made everything magically work (Hangouts was a famous example IIRC, though they've since added official Firefox support).

Rubbish. This is literally WebAuthn, a completely open standard. There is no hidden secret sauce here, proprietary vendor lock-in, nothing.

We’ve had the functionality forever with Yubikey and so on, the difference is the tight integration with these common platforms making for ease of use.

The website you are accessing knows nothing about your device, it’s just doing a protocol dance. You can do it too! I’m sure someone will create a crap, insecure, WebAuthn client so that you can keep using your passwords.

I look forward to using that crap insecure WebAuthn client. A private key I don't control is a much bigger security issue than a compromised password will ever be. Google currently has no plans of supporting linux for "Local user verification" or "Passkey sync". If it was a truly open standard, I don't see why that would be the case. Needing to use a Google account is the definition of propriety vendor lock-in. Relying on specific hardware is the reason why I haven't embraced Yubikeys.

I understand the assumption that the general population doesn't care to and shouldn't need to worry about managing their private keys. But there's nothing secure about not giving me the option to, if I want to.

https://developers.google.com/identity/passkeys/supported-en....

> The website you are accessing knows nothing about your device,

That is not correct. WebAuthn supports attestation of a hardware key storage, which means site operators can refuse to accept your keys unless you use a device from a white list.

It is bad when the dependency is phone only. Example: 2FA codes based on HOTP/TOTP are printable & exportable already, and you could use them on an external devices that are not a phone.

Passkeys are based on FIDO standards, so I believe a phoneless approach should work as well, given the proper device is available.

The bad part is that plenty of bad implementations exist for such external devices. For 2FA many, too many places allow just one device "for security" - which is total bs, of course. This was true for AWS until a couple of years ago, I didn't check this recently.

Google and Github get this right; but a lot of other parties just don't.

Imagine when google bans you like people get banned off Twitter…

“sorry your keys were revoked on chrome for an attempted search on an unauthorized topic” (so you can no longer access your bank website)

I imagine it’ll even get more dystopian as mistakes / bugs will happen and Google has no tech support

Then don’t store/sync your passkeys with Google.

That makes this an even worse idea. Imagine losing everything because your phone gets stolen.

Phone insurance should become real very soon.

Or use something like 1Password, LastPass, or any other password manager that ends up supporting Passkeys.

I use KeePassXC specifically so that I can publish my encrypted database to the open Internet and access it anywhere, from any platform.

Someone else in this thread linked to Webauthn supporting coming for KeePassXC.

Hopefully we end up with a variety of password manager options that support these standards and devices/browsers that allow you to use your own password manager for the passkey flow.

Until my bank starts offering an alternative to - screams of terror - SMS verification, KeePassXC currently serves all my needs.

(It also allows unlimited TOTP accounts, unlike things like Yubikey which only support up to, like, 30?)

Who’s going to write the software to read those keys and validate them?

Google and apple. That’s it.

> Basically am I the only one who doesn't think phone is my life and I don't want my life to be over if I lose my phone?

A huge percentage of internet users today don't own any devices other than their phone and most big corporations like Google want that percentage to become 100% in the near future because it's within their best interests if users have no control whatsoever over the device they rely on to live their life.

I don't know where you get the idea that a mobile device is needed

Reply on news.ycombinator.com