One of my biggest contributions at one place I worked was to dismantle their radius auth and replace it with token cert auth. It’s hard to write about that on a resume, because people tend to be more impressed with complexity than simplicity.
And if it is ever asked about, boy do you have some great stories about upgrading from a system whose protocol name referred to dial in modems and used MD5 to obfuscate passwords.
Clearly moving towards complex systems like RADIUS and SAML introduce even more moving parts that sit with interconnects between trusted and untrusted, internal and external components. That becomes a point of failure in the eyes of infrastructure companies.
The challenge here seems to be getting the IT world to understand the focus on availability in critical infrastructure - historically, the focus has been on availability first, integrity second, confidentiality third.
You could argue this shouldn't apply to VPN interfaces in to manage systems, but given the external dependencies of these systems, they feel far less likely to remain available than the kind of solutions the sector expects.
On a separate note though, critical infrastructure need to re-think their budgets to pay for their increased availability needs, given most of the commercial solutions are third party hosted "as a service" offerings.
Remember that critical industry is a sector where patching software is viewed as risky, because changing anything when it works is seen as unnecessary, and would often have weeks or months of pre-deployment testing. They work on a different time-base to the IT world.
The ability to do a "bypass" is nice in theory, but the need for this option will resonate with the "old guard", who will be able to use this external dependency to keep it out.
Personally I prefer smartcard-based solutions for MFA, since you can do all verification offline without requiring any third party to inject themselves into the chain. I found a good example of a vulnerability this year in Duo that just shows their validation logic is complex enough that one user was able to pass 2FA as another user [1].
That's probably your second worst case scenario, with the worst being an outsider being able to pass 2FA. A well-implemented smartcard scheme shouldn't fail in this way, as you're distributing validation logic to each device, rather than centralising it and relying on a "trusted outsider" to give a "yes or no".
[1] https://sensepost.com/blog/2021/duo-two-factor-authenticatio...
Checklist is a 90% solution which might help here. Or it might have been the case where the checklist failed.
From my experience, there’s a difference between trying to compromise someone with good opsec (many readers of hacker news) and compromising regular non technical people
Suppose BigCorp users are supposed to enroll the new tokens they all received at mfa.bigcorp.example which I dunno maybe they're reaching via a link from blog.thebigcorp.example because of course these organisations have a dozen different domains used interchangeably.
I can see how you could try to redirect some or all employees to mfa.b1gc0rp.example which you control, and that's an opportunity to steal their non-token credentials, but now their token doesn't actually work.
Even though they've enrolled with mfa.b1gc0rp.example you don't directly gain working token credentials for bigcorp.example this way, and almost as importantly for this attack, nor do they. So they're going to call the company IT desk.
I guess if you own a suitable token, you could conduct this as a spear phishing attack where the victim tries to enroll at your bogus site, then you replay the non-token credentials they used for that to enroll your real token on the real site, but again the victim doesn't end up with a working token, so it seems like you're up against the clock.
And while during the pandemic I'm sure new employees were routinely enrolled off-campus, I suspect that's just not the case in normal times, even at organisations which have a very broad work-from-home policy.
You definitely have a point with regard to non-transaction usage that requires long term access
It's involves some clever cryptography, and engineering. Here's an old ImperialViolet entry about it: https://www.imperialviolet.org/2018/03/27/webauthn.html
During enrollment the site gets a unique random-looking identifier, a public key and a signed message that proves your token knows the associated private key. It stashes the identifier and public key. They aren't secret.
During authentication the site gives back one or more identifiers to ask you to prove you've still got one of these tokens you enrolled, and if your token recognises the identifier for this DNS name, it can sign a new message with the corresponding private key proving you still have the token.
Now suppose I'm a scammer, I am trying to phish users of the site realsite.example with my phishing scam site fake.example but they all use FIDO tokens. I can get realsite.example to give me the IDs for tokens (perhaps I guessed the user name and password or got it earlier by phishing), but then I'm blocked. I could try a few things:
1. I give them the realsite.example ID and I pretend my site is realsite.example. The user is never bothered by this because their web browser knows this website isn't realsite.example, I'm clearly a scammer, my attempt is ignored.
2. I give them the real IDs from realsite.example but I admit to the web browser that this is fake.example. This doesn't work because those IDs are for realsite.example and my site is fake.example. There isn't any "Wrong name, override? Y/N" type pop-up, there's no way for any component to guess what happened, it just doesn't work. Maybe the user will retry a dozen times. Maybe they'll eventually spot that it's a scam. They can't give me working credentials for realsite.example because they aren't at realsite.example.
3. I give them a nonsense ID and I admit this is fake.example, this doesn't work, their token doesn't recognise the nonsense ID.
4. I have them enroll their token on fake.example. This "works" fine, but now all I can do is authenticate this user on my site, the resulting credentials are completely useless on realsite.example, these are credentials for fake.example and nothing about them is the same.
any VPNs support u2f?
You may still want to train the users not to accept any random request on the app, though. But this works (fairly) well and is cheap (no hardware token to buy).
https://docs.microsoft.com/en-us/azure/active-directory/auth...
The 57$/User of MS E5 is starting to look like a steal.
--
Seriously though - in your comment, you described the landscape of knowledge whereby it is EASY for any given corp to mis-step without a 'you' on staff or contract.
Now, as the NSA has released in the past best practices around security and such (like how to lockdown a linux box for example)
Wouldn;t it be prudent for the .gov to be able to present a salient security posture recommendation in such a format as you present above?
Meaning - WHY THE FUCK DONT WE HAVE A SECURITY.GOV WEBSITE THAT STATES EXACTLY HOW TO SECURE YOUR [THING] and CLICK HERE FOR EXPERTISE ON HOW TO SO???
We are in the Digital Nuke age. We should act as such.
You get the idea...
And besides, I only recently discovered - after proudly presenting myself as having a Masters in Engineering - that the title Engineer is considered poorly, a synonym to machine operator.
And to me, the Masters is the damning part of the title =)
The issue? A group of old professors chose to stop teaching a particular procedure.
Reason? Market prices of that procedure had began to be driven down by competing professionals.
She sounded so disappointed, as she should.
Never underestimate the power of greed against the well being of everyone else.
The cheaper the better from that POV
Lets stop assuming these things happen elsewhere to the same greed fueled extent.
Now that I think about it, I've actually rarely heard anything about single payer dental coverage, which is weird considering just how important dental health to life quality. Is dental work free in countries like Germany, the NL, Sweden etc?
The notable exception being dentistry. The dentists (mostly) fight tooth and nail not to be publicly funded; the reason, of course being that the state holds way more leverage than individuals - and rates are sure to plummet once the state foots the bill.
If I go to see my doctor, am admitted to hospital or whatever, I pay a small deductible - $20-40 - each time; once my expenses in a calendar year exceeds approx. $300, I get a waiver valid for the rest of the year, capping my direct medical expenses (excluding dentistry) at $300 a year.
For comparison, last time I had a tooth filled a few years ago, my dentist charged me $300 for a 20 minute job.
If you want more explicit guidance, IRS Pub 1075, DoD STIGs and other guides will literally tell you exactly what to do.
Egregious failure is always driven by lack of funding and/or motivation. Other failures are usually a result of a lack of defense in depth or compensating controls that missed something.
There are numerous ways of integrating VPNs with MFA ranging from a RADIUS integration to a SAML one. At Saas Pass the admin can choose and implement up to 15 different methods of MFA to VPNs ranging from FIDO keys to push approval to scanning encrypted barcodes to SMS (not recommended) etc...
Disclaimer: Worked on the design of some of the mfa interfaces for the SAML based VPNs and the access control policies.