Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

When MFA isn't MFA, or how we got phished

retool.com

Post reply on HN
Print view View original

231–240 of 287 posts

Re: When MFA isn't MFA, or how we got phished

#231

Post by bawolff »

cottsak wrote: post #199
bawolff wrote: post #64

Earlier quoted context omitted.

> I'm surprised Google encourages syncing the codes to the cloud... kind of defeats the purpose. Depends on what you think the purpose is. People talk about TOTP solving all sorts of problems, but in practise the only one it really solves for most setups is people choosing bad passwords or reusing passwords on other insecure sites. Pretty much every other threat model for it is wishful thinking. While i also think th…

great insight: > in practise the only one it really solves for most setups is people choosing bad passwords or reusing passwords on other insecure sites. Pretty much every other threat model for it is wishful thinking. Why is no one talking about this?

The other side of this is that (to pull numbers out of my hat) 90% of non-targeted attacks are password reuse and 9.9% are phishing with 0.1% being something else. The fact that TOTP doesn't solve phishing does get talked about.

Ultimately totp & sms based 2fa is used because it solves the real business problem that websites face (the business problem being when enough users get hacked they blame the business not themselves, so we just need to save most of them not all). Yes there is some fear mongering to make people sign up for 2FA, but it is actually solving a big problem effectively. It doesn't matter its not helpful in more fanciful scenarios since those scenarios are largely imaginary to begin with (for the average user).

Re: When MFA isn't MFA, or how we got phished

#232

Post by rlt »

V__ wrote: post #37
AYBABTME wrote: post #29

To deepfake the voice of an actual employee, they would need enough recorded content of that employee's voice... and I would think someone doing admin things on their platform isn't also in DevRel with a lot of their voice uploaded online for anyone to use. So it smells like someone with close physical proximity to the company would be involved.

One possibility would be to just call the employee and record their voice. One could pretend to be a headhunter.

I'm already cautious about answering calls from unknown numbers. This could be a good reason to be even more cautious.

Re: When MFA isn't MFA, or how we got phished

#233

Post by rmbyrro »

matsemann wrote: post #211
rmbyrro wrote: post #179

Earlier quoted context omitted.

I can understand how someone with my coworker's voice might lull myself into a false sense of urgency and safety. To the point of sharing an OTP code over the phone from a strange number? I'm sorry, no.

They could trivially spoof the number they're calling from to match.

Or I could call them on a known point of contact, like a phone number or IM.

Re: When MFA isn't MFA, or how we got phished

#234

Post by rmbyrro »

SoftTalker wrote: post #203
rmbyrro wrote: post #179

Earlier quoted context omitted.

I can understand how someone with my coworker's voice might lull myself into a false sense of urgency and safety. To the point of sharing an OTP code over the phone from a strange number? I'm sorry, no.

You could give them a false number and see what happens. That might trip up their script enough to reveal they aren't who they seem to be. Just play dumb -- "I can't understand why it's not working, that's the number on my phone...."

That's also a good idea.

Re: When MFA isn't MFA, or how we got phished

#235

Post by tlrobinson »

Wojtkie wrote: post #67
mistrial9 wrote: post #7

Earlier quoted context omitted.

how's that Zero Trust architecture working out for everyone ?

They mention in the article that their zero-trust architecture is what prevented the attacker from gaining access to on-prem data. So it seemed like it worked pretty well in mitigating the damage.

I'm curious if they actually mean "Zero trust" in the "perimeterless" sense (https://en.wikipedia.org/wiki/Zero_trust_security_model) or if they just mean their on-prem solution doesn't require trusting some central service operated by Retool.

Re: When MFA isn't MFA, or how we got phished

#236

Post by xorcist »

skeaker wrote: post #138
xorcist wrote: post #56

Stopped reading at "deepfake". It's the new advanced persistent threat, a perfect phrase to divert any resposibility. (Yes, there are deepfakes. Yes, there are APTs. This is likely neither.)

I am (genuinely, really asking) curious why you think so. I've got no hand in this, but the skepticism around phishing attacks from this site of all places really surprises me. People like Kevin Mitnick have done more sophisticated phishing with fewer tools. Why wouldn't someone intent on running a social engineering scam use one of the widely available voice faking technologies that are available now? Keep in mind t…

Making a meme is nothing like an interactive telephone conversation.

It's not that it's impossible, but it's not trivial either. But mainly, it's just unnecessary.

If the user is not fooled by a well crafted phishing, by doing the most trivial countermeasures such as calling back, they are not going to be fooled by a deepfake. In practice work on phishing is mostly better spent elsewhere. So while we shouldn't dismiss it completely, it's clearly not the case with a smallish company with limited economic value, so very unlikely the case here.

There has been a handful of highly profile media cases involving deepfake. None of which has held up on further investigation. It is understandable, nobody wants to be known as the one who didn't recognize his own kid on the phone, but the truth is more simple and actually helps us when designing countermeasures.

Re: When MFA isn't MFA, or how we got phished

#237

Post by mousetree »

tlrobinson wrote: post #235
Wojtkie wrote: post #67

Earlier quoted context omitted.

They mention in the article that their zero-trust architecture is what prevented the attacker from gaining access to on-prem data. So it seemed like it worked pretty well in mitigating the damage.

I'm curious if they actually mean "Zero trust" in the "perimeterless" sense ( https://en.wikipedia.org/wiki/Zero_trust_security_model ) or if they just mean their on-prem solution doesn't require trusting some central service operated by Retool.

The latter

Re: When MFA isn't MFA, or how we got phished

#238

Post by MaxBarraclough »

intrasight wrote: post #218
strken wrote: post #155

Earlier quoted context omitted.

I say "If this is a scam call please hang up now, otherwise give me an invoice or ticket number or name and department and I'll get back to you," and they usually do hang up. The case where you need to actually call your bank is really rare. Note that it's very important not to let them give you an actual phone number to call on. This sounds obvious but I know someone who hung up but called back on a number given by…

I'm going to add to this that "hang up" means physically do that. I've heard that many are tricked by the attacker playing a "dial tone" sound into the phone and thus keeping the line open and "answering" when you thought you called you bank.

You may be right that some people are tricked into thinking the call has been terminated by the caller, when in fact the caller is playing a dial tone over the line. It's worse than that though. In some telephone systems, the call is not ended when the callee hangs up.

https://security.stackexchange.com/questions/100268/does-han...

Re: When MFA isn't MFA, or how we got phished

#239

Post by crabbone »

Terretta wrote: post #173
crabbone wrote: post #170

MFA is a scam resulting from Google first, and then others wanting to get users' phone numbers associated with more data they collect on them. It provides no tangible security benefits, creates a lot of headache for IT department, creates big gaps in developer's productivity (if used in a programming company) and, actually, creates a new attack vector (phones are lost or stolen a lot more often than any other means o…

I don't understand: > Google first, and then others wanting to get users' phone numbers associated with more data they collect on them Perhaps you mean SMS 2FA, instead of a non phone number related MFA such as T-OTP?

Google were sued because they were selling to advertisers information about Android users that other advertising platforms couldn't possibly had. Advertisement data s.a. user preferences, their history of clicking on ads, browsing history etc would all be organized by the id derived from Android device. Once the court decided they cannot do that, and users should opt in to be tracked, they promptly created MFA that relied on collecting data about physical devices. Which they then again used to sell advertisement data.

The whole point of this exercise is not to enhance security, but to have an edge as an advertisement platform. If today you can trick the system into not using a phone, it's a temporary thing. The more users join, the tighter will be the system's grip on each individual user, and the "privilege" of not divulging your phone number will be taken away.

Google did this before with e-mail access for example, multiple times, actually. Remember how GoogleTalk used Jabber? -- Not having to use a proprietary chat protocol was a feature that made more users join. As soon as there were enough users, they replaced GoogleTalk with Hangouts or w/e it's called.

GMail used to provide standard SMTP / IMAP access, but they continuously undermined all clients other than Google's. Started with removing POP access. Then requiring mandatory TLS. Then requiring a bunch of nonsense "trusted application registration". Finally, this feature is now behind MFA, which makes it useless anywhere outside Google's Web client / Android app etc. All of this was delivered as a "security improvements", while giving no tangible security benefits. It was a move to undermine competition.

Re: When MFA isn't MFA, or how we got phished

#240

Post by corford »

tptacek wrote: post #177

We 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…

For others new to WebAuthn and Passkeys (like me), worth noting that Passkeys come with important privacy/ease-of-use trade-offs (nice summary here: https://blog.passwordless.id/webauthn-vs-passkeys)

Less of an issue though once more non-platform vendors start supporting them (e.g. Bitwarden https://bitwarden.com/passwordless-passkeys/)

Post reply on HN