Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

FYI: WebAuthentication spec is backdoored [1526792] #644

Closed
KOLANICH opened this issue Feb 10, 2019 · 12 comments
Closed

FYI: WebAuthentication spec is backdoored [1526792] #644

KOLANICH opened this issue Feb 10, 2019 · 12 comments
Labels

Comments

@KOLANICH
Copy link

KOLANICH commented Feb 10, 2019

Hi guys. I have looked onto WebAuthentication and I think we are really deep in shit. WebAuthentication spec is backdoored and already implemented.

  1. The spec allow websites to require a specific kind of Authenticator to be used.
  2. The spec allow websites to require remote attestation; remote attestation is done in the fashion it is done in TEE - using factory-provisioned secrets.
  3. For Android phones there is an Authenticator relying on SafetyNet and for Windows 10 - a one relying on Hello.
  4. For most of modern devices it is also possible to implement the stuff using TEEs, like SGX and TrustZone-based ones like Knox.

Because of prevalence of Google/Facebook/Twitter-only signin and/or reCaptha on websites, including browser fingerprinting reCaptchas v3 on login forms (!), big websites are expected to adopt this stuff violently, restrict signins only to a whitelist of Authenticators, requiring attestation and eliminating old good password authentication disrespect to losses of users not having these measures, because the lost users are unneeded and the measures are taken to get rid of these kinds of users: if a user doesn't have the authenticators, he is likely uses an old device (services don't need such a user, it is hard to convince them to pay for the bullshit promoted in ads, ones who can be convinced to pay, have already been convinced to buy new devices) or even worse, dares to oppose the policy and the trend by not buying devices with TEEs and rooting phones (websites don't need such users, they are more likely to violate ToS than housewives).

So we are in a deep ass. Very soon we will be unable to use most of websites.

How about free software projects and some sites still welcoming users like us?

We need a libre authenticator for that. Obviously it will be rejected by some large websites, but for privacy-friendly ones in order to use it it should at least ... exist. But currently there is no API to implement such authenticators, in order to implement it a user has to emulate a USB device. This is an extremily strange approach to architecture, so I have created https://bugzilla.mozilla.org/show_bug.cgi?id=1526792 and w3c/webauthn#1157 .

@Thorin-Oakenpants
Copy link
Contributor

I don't know what I'm meant to do with this, although I get it that you want to share, and yeah, I hate this kind of shit as well - monopolies or severely reduced competition

This is like how Android has effectively blocked all "clean" droids - go here: https://motherboard.vice.com/en_us/article/ev3qw7/how-to-quit-apple-microsoft-google-facebook-amazon and scroll way way way down to the google part near the end, or search for "When I arrived home from the Verizon store" .. and read on.

Google is scorching the Earth for 250 miles around the outside of the castle to ensure that no one can approach it.

It's like a walled garden, or a variant of EEE (extend, embrace, extinguish) and all the other shady shitty things that make the internet less of what it could be.

But there's nothing I can do about it in a user.js. Don't take this the wrong way... but for a project that is highly mature, why do I get so many new issues

issues

closing this, sorry

@Thorin-Oakenpants Thorin-Oakenpants changed the title WebAuthentication is screwed FYI: WebAuthentication is screwed [1526792] Feb 10, 2019
@KOLANICH
Copy link
Author

I don't know what I'm meant to do with this

In fact the end of the post contains an invitation to take part in standardizing the API for software Authenticators.

@Thorin-Oakenpants
Copy link
Contributor

I'm not qualified and know nothing about it, sorry

@yackermann
Copy link

@Thorin-Oakenpants As we mentioned during the WebAuthn conversation, you can do pure software implementation using HID lib/driver. @KOLANICH has not provided a good reasoning why this is not acceptable solution.

FIDO authenticators are inherently privacy centric. It does not matter if it is Security key, Google/Microsoft/Apple authenticator etc. It provides strong authentication, phishing protection, privacy, etc.

Lastly: And to defend LARGE "EVIL" CORPS: Those companies are having heated discussion on every call, on how to defend users privacy and security. Amount of hours spend on those conversations, and amount of time release of the standard was delayed, because someone thought about another privacy issues, is insane. If you don't believe me, you are free to go over 1000+ issues and pull requests and read all the discussions. They are publicly available at the end of the day.

@KOLANICH
Copy link
Author

KOLANICH commented Feb 11, 2019

you can do pure software implementation using HID lib/driver. @KOLANICH has not provided a good reasoning why this is not acceptable solution.

It is a overcomplex and non-portable solution, like a transrectal tonsillectomy. It is used only because there were no alternatives provided. We need a portable solution. A portable means I don't need to spend a lot of my time modifying an Authenticator to a platform and/or a platform for an authenticator. Some devices don't have root access, some don't have the needed kernel modules. Some are run on FreeBSD, some are browsers run in Wine. A native lib (all what is needed is to obtain a binary of it, for example by building) and especially a WebExtension (since no build is needed) are portable solutions.

FIDO authenticators are inherently privacy centric. It does not matter if it is Security key, Google/Microsoft/Apple authenticator etc.

SafetyNet is not root friendly. And a requirement to have a TEE on a device (non-user-controlled hardware) is completely inacceptable. So is a requirement to buy a device.

@yackermann
Copy link

SafetyNet is not root friendly. And a requirement to have a TEE on a device (non-user-controlled hardware) is completely inacceptable. So does a requirement to buy a device.

Safetynet only used for device attestation. Key management is done by secure enclave. It's a bad idea, but you can do pure software authenticator. I am not sure what exact reason to hate the TEE.

It is a overcomplex and non-portable solution, like a transrectal tonsillectomy. It is used only because there were no alternatives provided. We need a portable solution. A portable means I don't need to spend a lot of my time modifying an Authenticator to a platform and/or a platform for an authenticator. Some devices don't have root access, some don't have the needed kernel modules. Some are run on FreeBSD, some are browsers run in Wine. A native lib (all what is needed is to obtain a binary of it, for example by building) and especially a WebExtension (since no build is needed) are portable solutions.

Use hardware security keys.

@KOLANICH
Copy link
Author

KOLANICH commented Feb 11, 2019

I am not sure what exact reason to hate the TEE.

Because the TEEs pushed by companies are designed to violate my rights to do with the device I have bought everything I want. If companyes' positions are that it is OK to embed the devices preventing me from owning my device, I don't want to make a 1e-100 cent of money for the companies.

Safetynet only used for device attestation.

I don't have it on my device at all. My device doesn't contain any Google proprietary components. All the software (except Firefox) used is installed from F-Droid. And I am strictly against of using platform-locked vendor-locked authentifiers.

Use hardware security keys.

Don't order me, you are neither a king, nor an imperor.

@yackermann
Copy link

Ooookeeey... seems constructive...

@Thorin-Oakenpants Thorin-Oakenpants changed the title FYI: WebAuthentication is screwed [1526792] FYI: WebAuthentication [1526792] Mar 13, 2019
@Thorin-Oakenpants
Copy link
Contributor

I changed the title in case it seems to people that the user.js causes it to be "screwed"

@KOLANICH
Copy link
Author

@Thorin-Oakenpants, WebAuthentication spec is backdoored may be a better header

@KOLANICH KOLANICH changed the title FYI: WebAuthentication [1526792] FYI: WebAuthentication spec is backdoored [1526792] Mar 13, 2019
@Thorin-Oakenpants
Copy link
Contributor

That's fine. I just didn't want it to imply the user.js caused a problem (since this is it's repo)

@KOLANICH
Copy link
Author

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Development

No branches or pull requests

3 participants