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

211–220 of 287 posts

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

#211

Post by matsemann »

rmbyrro wrote: post #179
ketzo wrote: post #172

Earlier quoted context omitted.

You can't understand at all how someone with your coworker's voice might lull you into a false sense of urgency and safety? Security is a weak-link problem, not a strong-link one. You have to plan for the least security-minded people, the tired and stressed employee.

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.

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

#212

Post by codebje »

Terretta wrote: post #174
codebje wrote: post #158

Earlier quoted context omitted.

I've had a wide range of responses from people calling me when I tell them I won't give personal details out based on a cold call. A few understand immediately and are good about it. Most have absolutely no idea why I would even be bothered about an unexpected caller asking me for personal information. A few are practically hostile about it. None, to date, have worked for a company that has a process established for…

> None, to date, have worked for a company that has a process established for safely establishing identity of the person they're calling What's fun here is, the moment they ask you for anything, flip the script and start to try to establish a trust identity for the caller. Tell them you need to verify them, and then ask how they propose you do that. Choose your own adventure from there.

> Tell them you need to verify them, and then ask how they propose you do that.

Last time I did that, the caller said "but you can just trust that I'm from ." So I replied that they, likewise, could just trust that I'm me, and you could practically hear the light bulb click on. They did their best to help from there but their inbound lines aren't staffed effectively so my patience ran out before I reached an operator.

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

#213

Post by BenjiWiebe »

codebje wrote: post #164
macNchz wrote: post #133

Earlier quoted context omitted.

Definitely, sometimes they'll have a case number or agent id you can use to get back to them, but there are cases where you have to assume if it's important to them they'll continue to nag or reach out on another channel. I have had at least one situation where I spent a while trying to get back to a quite convincing/legitimate sounding caller this way, where, as I escalated through support people it became increasin…

I put in very limited effort in returning cold calls. The contact is being initiated by the other party, the interest in the exchange is theirs, and the onus on making it work is theirs. Companies, including banks, don't call you to protect _your_ interests, they call you to protect themselves.

Except some banks and credit card companies will call you to notify you of fraud on your account.

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

#214

Post by roamerz »

I was thinking about this the other night. Is there really a solution to this? Best case scenario lets say you have a hardware key and everything is sealed up really well. You get your phishing call but instead of asking for a MFA code they have a real time IA enhanced video call from your daughter or mom with a gun to her head and they just walk you through a set of steps that will expose your IT systems. Do you do as they demand with a loved one’s life at stake? Or maybe it’s a scam? What do you do? You have 5 seconds to decide. Me? I go John Wick on them but I’ve had more than 5 seconds so that doesn’t count.

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

#215

Post by transitionnel »

codebje wrote: post #158
macNchz wrote: post #100

Beyond having hardware keys, this scenario is why I really try to drive home, in all of my security trainings, the idea that you should instantly short circuit any situation where you receive a phone call (or other message) and someone starts asking for information. It's always okay to say, "actually, let me get back to you in a minute" and hang up, calling back on a known phone number from the employee directory, or…

I've had a wide range of responses from people calling me when I tell them I won't give personal details out based on a cold call. A few understand immediately and are good about it. Most have absolutely no idea why I would even be bothered about an unexpected caller asking me for personal information. A few are practically hostile about it. None, to date, have worked for a company that has a process established for…

Someone needs to standardize a simple reverse-authentication system for this.

For example whenever a caller is requesting sensitive information, they give you a temporary extension directing to them or an equal, and ask you to call the organization's public number and enter that extension. Maybe just plug the number into their app if applicable to generate a direct call.

Like other comments have mentioned, the onus should be on them. Also, they would benefit from the resultant reduction in fraud. Maybe a case study on fraud reduction savings could help speed the adoption process without having to invoke the FCC.

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

#216

Post by apostacy »

dvdhsu wrote: post #89
alsodumb wrote: post #83

Maybe it’s just me, but I am really skeptical about the DeepFake part - it’s a theoretically possible attack vector, but the only evidence they possibly could have to support this statement would be the employees testimony. Targeting a particular employee with the voice of a specific person this employee knows requires a lot of information and insider info. Also, I think the article spends a lot of effort trying to b…

Hi, David, founder @ Retool here. We are currently working with law enforcement, and we believe they have corroborating evidence through audio that suggests a deepfake is likely. (Put another way, law enforcement has more evidence than just the employee's testimony.) (I wish we could blog about this one day... maybe in a few decades, hah. Learning more about the government's surveillance capabilities has been interes…

This is an example of Google sabotaging a techology it doesn't like. I'm not saying it is a conspiracy. But by thwarting TOTP like this, Google is benefiting.

I really like TOTP. It gives me more flexibility to control keys on my end. And you can still use a Yubikey to secure your private TOTP key. But you can also choose to copy your private key to multiple hardware tokens without needing anyone's permission. Properly used, you can get most of the benefit of FIDO2 with a lot more flexibility.

I actually recently deployed TOTP, and everyone was quite happy with it. But knowing that Google is syncing private keys around by default, I no longer think we can trust it.

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

#217

Post by nextaccountic »

alsodumb wrote: post #83

Maybe it’s just me, but I am really skeptical about the DeepFake part - it’s a theoretically possible attack vector, but the only evidence they possibly could have to support this statement would be the employees testimony. Targeting a particular employee with the voice of a specific person this employee knows requires a lot of information and insider info. Also, I think the article spends a lot of effort trying to b…

> the only evidence they possibly could have to support this statement would be the employees testimony

I've set up my phone to record all calls. The employee could have too.

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

#218

Post by intrasight »

strken wrote: post #155
dataflow wrote: post #116

Earlier quoted context omitted.

> this scenario is why I really try to drive home, in all of my security trainings, the idea that you should instantly short circuit any situation where you receive a phone call (or other message) and someone starts asking for information. The trouble is, calling the number on the back of your card requires actually taking out your card, dialing it, wading through a million menus, and waiting who-knows-how-long for s…

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.

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

#219

Post by solatic »

alsodumb wrote: post #83

Maybe it’s just me, but I am really skeptical about the DeepFake part - it’s a theoretically possible attack vector, but the only evidence they possibly could have to support this statement would be the employees testimony. Targeting a particular employee with the voice of a specific person this employee knows requires a lot of information and insider info. Also, I think the article spends a lot of effort trying to b…

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 used to login, so vendors cannot be configured to decide to reject the login because it didn't use a hardware token.

If you have any vendors without SSO (like GitHub, because it's an Enterprise feature), you're lucky if they support hardware tokens (cool, GitHub does) and even luckier if their "require 2FA" option (which GitHub has, per organization) allows you to require hardware keys (which GitHub does not).

Distributing hardware keys to employees is one thing. Mandating them is quite another.

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

#220

Post by zamfi »

dataflow wrote: post #116
macNchz wrote: post #100

Beyond having hardware keys, this scenario is why I really try to drive home, in all of my security trainings, the idea that you should instantly short circuit any situation where you receive a phone call (or other message) and someone starts asking for information. It's always okay to say, "actually, let me get back to you in a minute" and hang up, calling back on a known phone number from the employee directory, or…

> this scenario is why I really try to drive home, in all of my security trainings, the idea that you should instantly short circuit any situation where you receive a phone call (or other message) and someone starts asking for information. The trouble is, calling the number on the back of your card requires actually taking out your card, dialing it, wading through a million menus, and waiting who-knows-how-long for s…

I think the parent poster is arguing that we should normalize this behavior not that there's no excuse for not calling the number back given the reality we have today.

You're saying it's natural for people not to want to call back and wade through a million menus, and I agree.

But the conclusion from this is that companies should change their processes so that calling back is easy, precisely because otherwise people won't do it.

And the more people that do it despite the costs, the more normalized it'll be, and the more companies will be incentivized to make it easier.

Post reply on HN