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

161–170 of 287 posts

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

#161

Post by oldtownroad »

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…

> …we believe they have corroborating evidence through audio that suggests a deepfake is likely…

Does that mean they have audio of the call?

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

#162

Post by hinkley »

GauntletWizard wrote: post #117
hinkley wrote: post #114

Earlier quoted context omitted.

Advice I haven't even followed myself: It's probably a good idea to program your bank's fraud number into your phone. The odds that someone hacks your bank's Contact Us page are small but not zero. The bedrock of both PGP and .ssh/known_hosts could be restated as, "get information before anyone knows you need it". Fraud departments contacting me about potentially fraudulent charges is always going to make me upset. J…

At least once I have gotten a terribly phrased and link-strewn "Fraud Alert" from a bank, reported it to said bank's anti-phisihing e-mail address, gotten a personalized mail that responded that it was in fact fraud and that they had policies against using third party subdomains like... And then found out the day later that yes, that was their real new anti-fraud tool and template. There will need to be jail time for…

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.

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

#163

Post by eddythompson80 »

u801e wrote: post #156

Unfortunately, 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.

Client side tls certificates are the worst of all the options. They only make sense fully managed or for server to server communication.

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

#164

Post by codebje »

macNchz wrote: post #133
tyingq wrote: post #123

Earlier quoted context omitted.

>This also applies to non-work related calls: someone from your credit card company is calling and asking for something? Call back on the number on the back of your card. There's a number of situations, not just credit card ones, where it's impossible or remarkably difficult to get back to the person that had the context of why they were calling. Your advice holds, of course, because it's better to not be phished. Bu…

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.

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

#165

Post by dspillett »

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…

> 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 really irritates me that some significant companies openly encourage customers to ignore this advice, teaching then had practise. The most recent case I know of is PayPal calling myself. It was actually thenm new cc account, I thought I'd setup auto payment but it wasn't so I was a child if days late with the first payment) but it so easily could have not been. The person on the other end seemed rather taken aback that I wouldn't discuss my account or confirm any details on a call I'd not started, and all but insisted that I couldn't hang up and call back. In the end I just said I was hanging up and if I couldn't call back than that was a them problem because at that point I had no way of telling if it was really the company or not. At that point she said she'd send a message that is could read via my account online, which did actually happen so it wasn't a scammer. But to encourage customers to perform unsafe behaviour with personal and account details is highly irresponsible.

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

#166

Post by e12e »

kerblang wrote: post #30
jeremyjh wrote: post #8

Earlier quoted context omitted.

They mean they are syncing the private key used to generate the tokens on demand.

Do all these 2FA apps - like say Microsoft Authenticator - have these hidden/not-so-hidden private keys? From other posts it sounds like you can view the token and write it down... MA doesn't have that, I don't think.

TOTP (Time-based one-time password) need a shared secret (and two synchronized clocks) to work, so yes.

FIDO2/WebAuthn relies on public key technology - so does also have a secret key - but is designed to be kept secret from the service/server one authenticates against.

For use - FIDO2 is more like a multi-use id. Like a driver's license many services accept as id. If you lose it - you don't restore a backup copy from a safe - you use your passport until you get a new one issued.

This makes more sense than with TOTP as the services only need your public key(id) on file.

https://en.wikipedia.org/wiki/Time-based_One-time_Password

https://en.m.wikipedia.org/wiki/WebAuthn

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

#167

Post by e12e »

itake wrote: post #24
unethical_ban wrote: post #10

Earlier quoted context omitted.

Syncing of "MFA codes" is really syncing of the secret component of TOTP (time based one time password). And it's a good thing, and damn any 2fa solution that blocks it. I don't want to go through onerous, incompetent, poorly designed account recovery procedures if a toddler smashes my phone. So I use authy personally, while a friend backs his up locally.

> I don't want to go through onerous, incompetent, poorly designed account recovery procedures if a toddler smashes my phone Why don't you use the printed recovery tokens?

> Why don't you use the printed recovery tokens?

I currently see 53 2fa tokens in my private bitwarden.

You expect me to print, keep safe and manually reset them all when I buy a new phone?

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

#168

Post by tyingq »

munk-a wrote: post #136
tyingq wrote: post #123

Earlier quoted context omitted.

>This also applies to non-work related calls: someone from your credit card company is calling and asking for something? Call back on the number on the back of your card. There's a number of situations, not just credit card ones, where it's impossible or remarkably difficult to get back to the person that had the context of why they were calling. Your advice holds, of course, because it's better to not be phished. Bu…

My mother recently started having to deal directly with utility bills and the like and this was some information we impressed very early on. You should never agree to billing or hand over CC/account information in a phone call you didn't initiate. She hasn't run into an issue yet - most utilities, online stores and other entities have call in numbers if you need to resolve a billing dispute. That random company you b…

Yeah, I'm talking about situations where it's a department that's not tied to the main call center. The credit card fraud people, for example[1]. Or, with Comcast, some guy saying your modem return was missing a piece, etc. Those are often hard to reach by calling the main number.

[1] For at least one place, the people that proactively identify things that could be fraud and call you...they aren't the same people you call to report fraud on your own. Why? No idea.

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

#169

Post by rmbyrro »

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…

> someone starts asking for information

Especially OTP codes.

I can't understand how someone works at a tech company and is clueless to the point of sharing an auth code over the phone. My grandma, sure, but a Retool employee? C'mon, haven't we all read enough of these stories?

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

#170

Post by crabbone »

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 of authentication).

Since Github now requires MFA, I'm throwing away my account: I'll never give them any physical evidence to connect me to other data they have on me.

In the company I work today (20-something thousands employees) the latest security breach was through MFA. Data was stolen. Perpetrators made jokes in company's Slack etc.

Last time I had to upgrade my phone (while working for the same company), it took IT about two weeks to give me all the necessary access again, which required a lot of phone calls, video conferences, including my boss and my boss' boss.

It's mind-boggling that this practice became the norm and is recommended by IT departments even of companies who have nothing to gain from collecting such data.

Post reply on HN