In our eternal quest to fix the long tail of security issues, I think the next step after WebAuthn is to get more eyeballs on the TLS certificate racket (since it sounds like WebAuthn depends on it working). Which I want to rant about:
A bunch of old companies who were early movers got their root certs in lots of devices, and now we depend on this opaque list of dozens of random companies. And now OSes and browsers are making it difficult or impossible to change that list or even use self-signed certs.
For example, the vast majority of Python applications use certifi as the root store, which last I checked pulls all the certs over HTTPS from Firefox’s Mercurial instance, through an ancient Ubuntu box, into billions of clients!
To clarify I don’t think certifi’s process is necessarily broken/vulnerable, just overly complex and fragile given the criticality. And really my main point is that this is the root cert handling process that we do see. Imagine the shitshow going on inside some of these ancient certificate authorities.
Mozilla takes the security of its source code pretty seriously, e.g. they recently launched cargo-vet. I guess the Ubuntu box is https://mkcert.org/ which looks like its volunteer-operated.
The machine hosting mkcert.org is the Ubuntu box, at least last I checked like a year ago. It’s a digitalocean IP and I found some other metadata (can’t remember where) that revealed an older LTS version. That may have changed though.
I’m really glad people are shining some light on this, it’s something I’ve been telling people about for ages. In my penetration testing activities I will often password spray some credential (bonus fun fact, if a sysadmin changes your password in AD it’s not required to meet password policies. changeme123 strikes again) and land on a Duo push page. If you get even like 5 successfully guessed accounts all with Duo enabled, you only need one to get internal access. People discount how often real attackers deal in bulk and not just single targets, it’s rarely about one person and more about finding the one thing that makes it all crumble.
I also really hope that more people can figure out how to integrate the WebAuthN and other solutions into real AD environments, because in my experience that is where tons of the actual organizational risk is to most large companies and entities and people often times discount that to personal security.
Is the problem that when you’re on the push page you know you’ve got a valid cred and can try to login at likely times someone might be logging in (so they accidentally say yes to the push for your login)?
Sorry, but that a really bad take these days. The webauthn/fido 2fa protects you from putting the password in the wrong page in the first place. Given enough time, you will get successfully phished. But fido will not sign the auth response to the wrong domain.
Then there are also all the ways your password security doesn’t matter: bugs in software that generated it, recovery from captured traffic, database dumps, hacked desktop, etc. A strong and unique password helps. It’s not enough if you get personally targeted for access.
Using an auto-filling password manager is honestly enough for a technical person to reduce their chance of being phished to near-zero. 99% of the time I get domain-checked password filling and that is enough to reduce the fatigue that I can be super careful and suspicious the last 1% of the time.
Don’t get me wrong, U2F is better (and I use it for a few extra sensitive services) but I’m not sure if I agree with “Given enough time, you will get successfully phished”
I have nothing against 2FA, but since so many 2FA systems are bad or broken it underscores that one should not give up and make a crap password because “2FA will save you”.
Two factor? Push notifications are the password less future! Have some crusty app that needs a password and a second factor? No problem! Just get some generated password from confirming a push notification and for the second factor …. Just confirm another push notification request…This is literally how my workplace does authentication now. It’s insane. I wouldn’t even be surprised if the Uber employee was bit by the same issue.
Honestly I’d rather just use a kdf keyed with the hash of a master password and the webpki authenticated domain name, hashed then concat, of the service I’m authenticating into. Still sucks for cases where I can’t control the accurate presentation of domain names or them being authentic, but I feel it’s better than any of the 2FAs I’ve been forced to use. I’ll feel better about hardware stuff when I can feel safe knowing I’m not permenantly screwed if all of my hardware keys magically got destroyed simultaneously in some unfortunate boating accident.
Great article!
In our eternal quest to fix the long tail of security issues, I think the next step after WebAuthn is to get more eyeballs on the TLS certificate racket (since it sounds like WebAuthn depends on it working). Which I want to rant about:
A bunch of old companies who were early movers got their root certs in lots of devices, and now we depend on this opaque list of dozens of random companies. And now OSes and browsers are making it difficult or impossible to change that list or even use self-signed certs.
For example, the vast majority of Python applications use certifi as the root store, which last I checked pulls all the certs over HTTPS from Firefox’s Mercurial instance, through an ancient Ubuntu box, into billions of clients!
https://github.com/certifi/python-certifi/blob/939a28ffc57b1613770f572b584745c7b6d43e7d/Makefile#L2
https://github.com/Lukasa/mkcert/blob/5e1e522b8dcafc3829fda1b8a1a09332b48b8798/main.go#L30
To clarify I don’t think certifi’s process is necessarily broken/vulnerable, just overly complex and fragile given the criticality. And really my main point is that this is the root cert handling process that we do see. Imagine the shitshow going on inside some of these ancient certificate authorities.
Oh that’s a fascinating piece of crucial internet security infrastructure I was unaware of.
Which bit is the “ancient Ubuntu box” - is that hg.mozilla.org?
Mozilla takes the security of its source code pretty seriously, e.g. they recently launched cargo-vet. I guess the Ubuntu box is https://mkcert.org/ which looks like its volunteer-operated.
Wow, the perfect https://xkcd.com/2347/
The machine hosting mkcert.org is the Ubuntu box, at least last I checked like a year ago. It’s a digitalocean IP and I found some other metadata (can’t remember where) that revealed an older LTS version. That may have changed though.
I’m really glad people are shining some light on this, it’s something I’ve been telling people about for ages. In my penetration testing activities I will often password spray some credential (bonus fun fact, if a sysadmin changes your password in AD it’s not required to meet password policies.
changeme123strikes again) and land on a Duo push page. If you get even like 5 successfully guessed accounts all with Duo enabled, you only need one to get internal access. People discount how often real attackers deal in bulk and not just single targets, it’s rarely about one person and more about finding the one thing that makes it all crumble.I also really hope that more people can figure out how to integrate the WebAuthN and other solutions into real AD environments, because in my experience that is where tons of the actual organizational risk is to most large companies and entities and people often times discount that to personal security.
Is the problem that when you’re on the push page you know you’ve got a valid cred and can try to login at likely times someone might be logging in (so they accidentally say yes to the push for your login)?
Note that none of the 2FA attacks matter if your password is secure. So using secure and unique passwords is still very effective!
Sorry, but that a really bad take these days. The webauthn/fido 2fa protects you from putting the password in the wrong page in the first place. Given enough time, you will get successfully phished. But fido will not sign the auth response to the wrong domain.
Then there are also all the ways your password security doesn’t matter: bugs in software that generated it, recovery from captured traffic, database dumps, hacked desktop, etc. A strong and unique password helps. It’s not enough if you get personally targeted for access.
Using an auto-filling password manager is honestly enough for a technical person to reduce their chance of being phished to near-zero. 99% of the time I get domain-checked password filling and that is enough to reduce the fatigue that I can be super careful and suspicious the last 1% of the time.
Don’t get me wrong, U2F is better (and I use it for a few extra sensitive services) but I’m not sure if I agree with “Given enough time, you will get successfully phished”
I have nothing against 2FA, but since so many 2FA systems are bad or broken it underscores that one should not give up and make a crap password because “2FA will save you”.
A strong password is still necessary to prevent physical device theft being an instant win, yes.
Two factor? Push notifications are the password less future! Have some crusty app that needs a password and a second factor? No problem! Just get some generated password from confirming a push notification and for the second factor …. Just confirm another push notification request…This is literally how my workplace does authentication now. It’s insane. I wouldn’t even be surprised if the Uber employee was bit by the same issue.
Honestly I’d rather just use a kdf keyed with the hash of a master password and the webpki authenticated domain name, hashed then concat, of the service I’m authenticating into. Still sucks for cases where I can’t control the accurate presentation of domain names or them being authentic, but I feel it’s better than any of the 2FAs I’ve been forced to use. I’ll feel better about hardware stuff when I can feel safe knowing I’m not permenantly screwed if all of my hardware keys magically got destroyed simultaneously in some unfortunate boating accident.