This is the biggest reason why MFA codes shouldn't be in the cloud. Use SMS-based MFA which is much more fool-proof though a pain in the ass. I have stopped using software based MFAs for this particular reason.
When MFA isn't MFA, or how we got phished
261–270 of 287 posts
Re: When MFA isn't MFA, or how we got phished
#262Earlier quoted context omitted.
One problem with hardware keys is still SaaS vendor support. There is a very narrow path for effective enforcement: require SSO, then require hardware tokens at the SSO level. But even that is difficult to truly enforce, because the IdP often has "recovery" mechanisms that grant access without a hardware key. Google is also guilty of not adding a claim to the OIDC/SAML response verifying that a hardware token was use…
If your organization is rich enough to buy hardware keys for everybody, but too stingy to pay for GitHub Enterprise, I'm not sure what to say.
Hardware keys are much cheaper than GitHub enterprise
Re: When MFA isn't MFA, or how we got phished
#2631. install pass otp
2. pass otp add whatever/otp/me
3. paste in "otpauth://totp/whatever?secret=whateveritis
4. pass git init; push to remote
Now you you have MFA on any device that has git and your gpg key.
Re: When MFA isn't MFA, or how we got phished
#264Earlier quoted context omitted.
Yubico's U2F security key (good for FIDO2, WebAuthn, etc.) is $25, each member of your organization needs only 1 key (if they lose their key, they can get another one from IT, which can remove the old key and enroll the new one for them), with a handful of IT personnel possibly having more than 1 key for backup (this is less necessary when a group of IT holds admin permissions, as they serve as key backups for each o…
The universe I'm in is the one where you have to staff the IT department and they have to support the device. The IT department costs way more than $21/month. You have a valid point that we need SaaS vendor support for SAML/whatever, but GitHub, specifically, supports SSO. Yeah, it costs money to get that feature, but security doesn't just happen. Security is expensive, but it's more expensive not to have it. In this…
I've personally worked for multiple startups where rolling out hardware keys did not require making additional IT hires (we're talking about companies smaller than ~50 people). Perhaps at BigCo size, you end up needing dedicated personnel to support a hardware key rollout at that scale, but at that scale you have the budget for GitHub Enterprise anyway so the point about pricing is moot; at BigCo size there is also even more of an incentive to roll out hardware keys since you're that much more likely to get spear phished.
Re: When MFA isn't MFA, or how we got phished
#265Unfortunately, MFA has become synonymous with SMS, email, and OTP. All of these methods require sharing a secret between two parties without any way to verify the authenticity of either party. Key based authentication where both parties have private keys that are not shared is a much better alternative. Unfortunately, client side TLS certificates, which are application level protocol agnostic, never really caught on.
There is U2F/FIDO keys / passkeys which are what you describe, latter just very recently becoming widely available. When/if they become successful is another question. U2F/FIDO etc keys are only supported by a subset of websites.
But they're not application level protocol agnostic. Based on my understanding, they require use of HTTP. If I want to get MFA using an email client communicating via SMTP and IMAP, then the email client needs to be able to interact with the HTTP API.
Re: When MFA isn't MFA, or how we got phished
#266Earlier quoted context omitted.
Zero Trust is such a bad branding for how the architecture works. It's just "always prove" architecture.
“Always prove” and “zero ambient trust” are basically the same thing, no? Perhaps “authenticate everything, everywhere” is better, but falls into the trap of trying to define “everywhere” and “everything”: should every single client application have to authenticate? Should you have to authenticate Ethernet frames?
I think we may mean the same thing, but zero trust has a connotation of negative rights, versus always prove is a way of framing things in a more positive assertion. At least that's worked for me at the last couple of places i've been.
Should every client application have to authenticate and authorize? Probably not every but the overwhelming majority probably and those that don't should have a good justification as to not. The challenge after that is "how long is this good for?".
Re: When MFA isn't MFA, or how we got phished
#267Very sophisticated attack, I would bet most people would fall for this. I'm surprised Google encourages syncing the codes to the cloud... kind of defeats the purpose. I sync my TOTP between devices using an encrypted backup, even if someone got that file they could not use the codes. FIDO2 would go a long way to help with this issue. There is no code to share over the phone. FIDO2 can also detect the domain making th…
Not surprised. A team at Google identified this as a vector to juice growth, submitted the metrics which now govern their PSC and didn’t add the necessary counter-metrics to measure negative effects. That’s normal because that’s how the game is played. All the way up the chain to the org leader, there is no incentive to not do this.
You live in a funny alternate reality. You should consider what it might be like to live in one where everyone else isn't dumber than you.
I will tell you a truth: People who think they're smarter than everyone else are generally missing important context or information.
Re: When MFA isn't MFA, or how we got phished
#268Earlier quoted context omitted.
There is U2F/FIDO keys / passkeys which are what you describe, latter just very recently becoming widely available. When/if they become successful is another question. U2F/FIDO etc keys are only supported by a subset of websites.
But they're not application level protocol agnostic. Based on my understanding, they require use of HTTP. If I want to get MFA using an email client communicating via SMTP and IMAP, then the email client needs to be able to interact with the HTTP API.
You can use FIDO tokens for other protocols: I use it for SSH, for example since OpenSSH 8.2 or so.
Re: When MFA isn't MFA, or how we got phished
#269Earlier quoted context omitted.
Last time I talked to someone about this they pointed out that fraud depts are often outsourced. Which is a lovely plan because now your customers hate you for something an entirely different company did to them. And also they are directing you away from the official website every single time you interact with them. I'm not sure what grounds you issue arrest warrants on, but I appreciate the sentiment.
Ironically, fraud. They have done substantial financial and "real" harm by pretending to be competent at things that they are clearly not, and have been a combination of remiss in their duties and complicit in the crimes of fraudsters. Sufficiently advanced incompetence is indistinguishable from malice, and should be prosecuted as such.
Years ago I bought a tv. Clear on the other side of town. When I got home I had a message from the fraud dept about charges. I called them up to explain I did in fact buy that tv.
They weren’t calling about the TV. They were calling about the car wash I stopped to get near my old neighborhood on the way home. For $8. Wat.
And for a while they would flag me every time I went on a road trip or travelled, because they pegged me as a non traveler. I travel, but quality over quantity. And you’re basically psychologically fencing me into a profile you’ve written about me that’s wrong by punishing me every time I step out of it? Fuck you.
Re: When MFA isn't MFA, or how we got phished
#270We use OTPs extensively at Retool: it’s how we authenticate into Google and Okta, how we authenticate into our internal VPN, and how we authenticate into our own internal instances of Retool They should stop using OTPs. OTPs are obsolete. For the past decade, the industry has been migrating from OTPs to phishing-proof authenticators: U2F, then WebAuthn, and now Passkeys†. The entire motivation for these new 2FA schem…
Are there self-hosted versions of something akin to what okta does? Push notifications with a validation step that the actual user initiated the authn request?
Knowing how dead simple TOTP is technically, it's blown my mind that more companies don't host their own totp authn server.