Huh, so I'm stupid I guess, but how is MFA phish proof? Why did Kurt's commit access get revoked?
Kurt Got Got
221–230 of 256 posts
Re: Kurt Got Got
#222Huh, so I'm stupid I guess, but how is MFA phish proof? Why did Kurt's commit access get revoked?
The commit access thing is a joke. I think it's a joke. It's mostly a joke.
MFA is not in general phish-resistant. But Passkeys, U2F, and FIDO2 generally are, because they mutually authenticate; they're not just "one time passwords" you type into a field, but rather a cryptographic protocol running between you and the site.
Re: Kurt Got Got
#223Earlier quoted context omitted.
That would be great, but > Fly.io supports Google and GitHub as Identity Providers[1] How about you just support SAML like a real enterprise vendor, so IdP-specific support isn't your problem anymore? I get it, SAML is hard, but it's really the One True Path when it comes to this stuff. [1] https://fly.io/docs/security/sso/
SAML is awful, maybe the worst cryptographic protocol ever devised, and we won't implement it unless we absolutely have to. OIDC is the future. I'm not exaggerating; you can use the search bar and find longer comments from me on SAML and XMLDSIG. You might just as well ask when we're going to implement DNSSEC.
I certainly see you whining a lot about SAML in your history. This lines up with my "SAML is hard" comment above -- SAML is filled with footguns and various perils, but that doesn't necessarily make it bad. OIDC is certainly better in a few aspects (note trading XML parsing for JSON parsing is not one of them), but the killer SAML feature that you (and by you, I mean fly.io, to be clear) is missing is being IdP-agnostic. You cannot reasonably expect that those two vendors will cover even half of your potential enterprise user base; and yes, for anyone working in an even remotely regulated industry, not being compatible with our SSO ensures you get dropped even before the evaluation phase.
My favourite slop-generator summarizes this as "While SAML is significantly more complex to implement than OIDC, its design for robust enterprise federation and its maturity have resulted in vendors converging on a more uniform interpretation of its detailed specification, reducing the relative frequency of non-standard implementation quirks when dealing with core B2B SSO scenarios." That being said, if your org is more B2C, maybe it makes sense you haven't prioritized this yet. You'll get there one day :)
Re: Kurt Got Got
#224Earlier quoted context omitted.
> there is a very simple way to execute code from an USB stick: the USB stick pretends it's a USB keyboard and starts sending input to access a terminal Good systems these days won't accept such a "keyboard" until it's approved by the user.
Which systems ask before allowing you to use a keyboard you just plugged in over USB? Windows, Ubuntu, Fedora certainly don't, at least not by default.
Mine. Not asking whoever happens to have local physical access interactively, strictly speaking, as that just papers over one of the problems; but controlling what Human Input Devices are allowed when plugged in, by applying rules (keyable on various device parameters) set up by the administrator.
Working thus far on NetBSD, FreeBSD, and Linux. OpenBSD to come when I can actually get it to successfully install on the hardware that I have.
* https://jdebp.uk/Softwares/nosh/guide/user-virtual-terminal-...
In principle there's no reason that X11 servers or Wayland systems cannot similarly provide find-grained control over auto-configuration instead of a just-automatically-merge-all-input-devices approach.
Re: Kurt Got Got
#225Earlier quoted context omitted.
A USB can pretend to be just about any type of device to get the appropriate driver installed and loaded. They can then send malformed packets to that driver to trigger some vulnerability and take over the system. There are a _lot_ of drivers for devices on a default windows install. There are a _lot more_ if you allow for Windows Update to install drivers for devices (which it does by default). I would not trust all…
Do people still commonly use USB for removable storage? I kinda assumed it was all SD/microSD now.
They certainly still plug those SD/TF cards into USB card readers that present themselves as USB mass storage devices.
Re: Kurt Got Got
#226Earlier quoted context omitted.
SAML is awful, maybe the worst cryptographic protocol ever devised, and we won't implement it unless we absolutely have to. OIDC is the future. I'm not exaggerating; you can use the search bar and find longer comments from me on SAML and XMLDSIG. You might just as well ask when we're going to implement DNSSEC.
I certainly see you whining a lot about SAML in your history. This lines up with my "SAML is hard" comment above -- SAML is filled with footguns and various perils, but that doesn't necessarily make it bad. OIDC is certainly better in a few aspects (note trading XML parsing for JSON parsing is not one of them), but the killer SAML feature that you (and by you, I mean fly.io, to be clear) is missing is being IdP-agnos…
"SAML is filled with footguns and various perils" is in fact why it's bad. You don't look at an archaic cryptosystem full of design flaws and go "skills issue". The "skills issue" would be using it at all. Sorry, SAML is dead.
Re: Kurt Got Got
#227Earlier quoted context omitted.
That would be great, but > Fly.io supports Google and GitHub as Identity Providers[1] How about you just support SAML like a real enterprise vendor, so IdP-specific support isn't your problem anymore? I get it, SAML is hard, but it's really the One True Path when it comes to this stuff. [1] https://fly.io/docs/security/sso/
SAML is awful, maybe the worst cryptographic protocol ever devised, and we won't implement it unless we absolutely have to. OIDC is the future. I'm not exaggerating; you can use the search bar and find longer comments from me on SAML and XMLDSIG. You might just as well ask when we're going to implement DNSSEC.
It's so bad
Here is a major vulnerability we disclosed earlier this year:
Re: Kurt Got Got
#228Earlier quoted context omitted.
What I heard about the Stuxnet attack was different from what you are saying: The enrichment facility had an air-gapped network, and just like our air-gapped networks, they had security requirements that mandated continuous anti-virus definition updates. The AV updates were brought in on a USB thumb drive that had been infected, because it WASN'T air-gapped when the updates were loaded. Obviously their AV tools didn'…
Do you have any sources that the infected USB contained AV updates? I can't find any sources saying that..
This was years ago by word of mouth within channels. AFAIK it wasn't classified, but maybe the guy who told me goofed.
Re: Kurt Got Got
#229Earlier quoted context omitted.
I mean the problem with Passkeys is that they're unsuitable as the sole login method for an account. They're great as a stronger "keep me logged in" for certain devices but they're something you have and they don't survive a fire. And so every service that offers Passkeys also has to offer a reset mechanism and a backup auth flow if you're on a device without the Passkey. Any site that wants to phish you will either…
You can do Passkeys entirely in software with KeePassXC.
Let me preface this by saying I use passkeys with KeepassXC.
According to WebAuthn, this is not true. Such passkeys are considered "synced passkeys" which are distinct from "device bound" passkeys, which are supposed to be stored in an HSM. WebAuthn allows for an RP to "require" (scare quotes) that the passkey be device bound. Furthermore, the RP can "require" that a specific key store be used. Microsoft enterprise for example requires use of Microsoft Authenticator.
You might ask, how is this enforced? For example, can't KeepassXC simply report that it is a hardware device, or that it is Microsoft Authenticator?
The answer is, there are no mechanisms to enforce this. Yes, KeepassXC can do this. So while you are actually correct that it's possible, the protocol itself pretends that it isn't, which is just one of the many issues with passkeys.