-
Notifications
You must be signed in to change notification settings - Fork 523
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
Comments
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.
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 closing this, sorry |
In fact the end of the post contains an invitation to take part in standardizing the API for software |
I'm not qualified and know nothing about it, sorry |
@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. |
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.
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. |
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.
Use hardware security keys. |
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.
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.
Don't order me, you are neither a king, nor an imperor. |
Ooookeeey... seems constructive... |
I changed the title in case it seems to people that the user.js causes it to be "screwed" |
@Thorin-Oakenpants, |
That's fine. I just didn't want it to imply the user.js caused a problem (since this is it's repo) |
Hi guys. I have looked onto WebAuthentication and I think we are really deep in shit. WebAuthentication spec is backdoored and already implemented.
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 .
The text was updated successfully, but these errors were encountered: