Initial Thoughts on FIDO
If you're involved in computer security and authentication,you might know about the FIDO Alliance. If you haven't, you know about them now given the giant marketing push about the great cloud-controlled, passwordless future we have ahead of us. The FIDO Alliance stories are pushed everywhere. They're all breathlessly reported as solving password problems and phishing in one fell swoop:
- https://krebsonsecurity.com/2022/05/your-phone-may-soon-replace-many-of-your-passwords/
- https://arstechnica.com/information-technology/2022/05/how-apple-google-and-microsoft-will-kill-passwords-and-phishing-in-1-stroke/
- https://macdailynews.com/2022/05/05/apple-google-and-microsoft-support-fido-passwordless-sign%e2%80%91ins/
- https://in.mashable.com/tech/31285/passwordless-login-is-the-future-apple-google-microsoft-are-making-it-a-reality
- https://venturebeat.com/2022/05/05/google-goes-passwordless/
- https://www.msn.com/en-in/finance/topstories/passwordless-is-the-future-apple-google-microsoft-to-roll-out-fido-passkey-tech/ar-AAWYjWQ
- https://www.androidheadlines.com/2022/05/fido-alliance-authentication-google-apple-microsoft-coming.html
- https://www.theverge.com/2022/5/5/23057646/apple-google-microsoft-passwordless-sign-in-fido
- https://www.cnet.com/tech/services-and-software/apple-google-microsoft-back-fido-tech-to-dump-passwords-on-websites-and-apps/
- https://www.zdnet.com/article/google-apple-microsoft-make-a-new-commitment-for-a-passwordless-future/
- https://www.windowscentral.com/microsoft-google-and-apple-want-you-say-farewell-passwords
And the list goes on ad infinitum. After reading a few of these posts, one starts to notice how similar they are in content. Almost like the sites were fed the same talking points memo and press release.
I'm all for secure, multi-factor authentication to augment passwords and further secure access to various websites, servers, services, etc. Think of services as your email, your (anti) social media, files, etc. I'm 100% for self-hosting and open protocols so I can host my own services and provide FIDO-compatible authentication between them. A couple of things in the spec and the oft-quoted FAQ caught my eye:
0. Google engineers wrote most of these standards. The sheer number of Google affiliations on each standard is concerning. I'm weary because Google is doing what every company has done in the past, flood standards boards with their own people and make the standard work for their interest. Just look at the FLoC/Privacy Sandbox mess. It's great for Google and pretty much no one else. Apple is raising the walls on their walled garden. Interestingly, I haven't seen a single Apple engineer listed in any of these specifications.
1, The reliance on Bluetooth. In this FAQ there is the question and answer about Bluetooth(BT):
"Is it safe for the user do to FIDO sign-in on a nearby device using Bluetooth?
The FIDO caBLE protocol uses Bluetooth to verify physical proximity and does not depend on Bluetooth security properties for the actual security of the sign-in. Instead, it uses standard cryptographic primitives at the application layer to protect data."
They didn't answer the question, rather they sidestepped it. Using BT means you have to have BT enabled and open. BT as implemented on hundreds of millions of devices is vulnerable to all sorts of exploits. Some of this is patched in software, a lot of it is in the chipset firmware. Almost every year, we see a new exploit that affects tens to hundreds of millions of devices:
2017: https://www.theverge.com/2017/9/12/16294904/bluetooth-hack-exploit-android-linux-blueborne
2019: https://arstechnica.com/information-technology/2019/08/new-attack-exploiting-serious-bluetooth-weakness-can-intercept-sensitive-data/
2020: https://www.tomsguide.com/news/android-bluetooth-hack
2021: https://threatpost.com/braktooth-bluetooth-bugs-exploit-poc/176036/
They all end in the same advice: "you should turn Bluetooth off when you’re not using it."
So now, to use this amazing new FIDO multi-device auth, I either have to leave BT on all the time and risk remote exploit or go through the multiple-taps to enable BT to do an auth, and have all the devices paired in advance. I have to enable/disable BT every time I want to login to a service that offers/requires FIDO auth. Or I use a usb-key, Near Field Communications, or something else to share the keys between devices.
2. Can I self-host my own Identity Service?
I don't have any accounts at Google, Microsoft, nor Apple. I run and host my own cloud (just my own servers instead of someone else's server). Digging through the confusing list of specifications, I find references to servers and providers. Specifically, "2.2 FIDO UAF Server: The FIDO UAF server is conceived as being deployable as an on-premise server by Relying Parties or as being outsourced to a FIDO-enabled third-party service provider." It's subtle, but basically, I should be able to run my own server and work within the FIDO ecosystem without issue. However, the probable reality will be that only the "third-party service providers" are honored. And given that Google engineers are the most numerous authors of the standards, only "the big cloud providers" will be allowed to be these third-party service providers.
I see this as the next X.509 push. X.509 was going to solve all authentication and identity issues at the time. The X.509 certificates were going to be ubiquitous and strongly tie your client certificate to your access controls and capabilities on third party sites (web sites, file servers, etc). It was deployed by big businesses, but quickly became a management nightmare. It is used by the entire HTTPS/TLS ecosystem, but mostly has a one way "we define what's valid and you'll like it" approach. Can I run my own Certificate Authority? Yes. Can I get the CA accepted as valid in your browser? Not without work on your end. Can you live without a CA on the modern Internet? Yes, I did it for years.
Are you basically excluded from the modern Internet if you run your own CA and only use your own TLS certs? Yes. Cartels exist and are accepted in some industries.
3. All of this still relies on a password.
The hand-wavy answer to "what if I lose my device?" is basically, "it's all in the cloud, so login to your cloud with your password and everything is pulled back down". Uhh, so every attacker will aim for phishing the cloud login, exploiting your backups, etc. The exact same problem FIDO is supposed to fix. What if I forget my core cloud password to unlock all this amazing FIDO work? What if I post the password to my cloud account on a sticky note and use the name of my pet as the password? Something about cards, houses, slight breezes.
Can I use a smart-card with secure vault/enclave to store the original password/private-public key combos? Can I clone this smart-card so I have multiple copies in multiple locations to avoid the inevitable "I lost the card to bad memory, or fire, or flood, or theft, etc?" More thoughts on the secure storage of secrets in future posts.
For now, these are my first thoughts after reading way too many copycat stories and most of the FIDO specifications. I look forward to open source FIDO-compatible/certified servers and software that I can operate myself and interoperate with others. I'll hold my breath until that happens.