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

221–230 of 287 posts

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

#221

Post by tortue0 »

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…

I've had my cable company call me directly about an account issue and told them I couldn't validate it was them and the person got somewhat irate with my response, insisting there was no one I could call to verify them and that it has to be handled on that call. Turns out it was just a sales call (up selling a product) - which probably speaks to the level of talent they hire for that.

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

#222

Post by dataflow »

zamfi wrote: post #220
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 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…

We certainly should normalize this, but my point was that it's going against the grain, so efforts like this may be in vain without a bigger lever to pull. e.g., I imagine you'd need to convince some sort of authority (CISA? FIPS? not sure whom the right entity is) to point out the best practices here before organizations start paying attention.

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

#223

Post by shortcake27 »

OJFord wrote: post #187
lxgr wrote: post #182

Earlier quoted context omitted.

> someone from your credit card company is calling and asking for something? Call back on the number on the back of your card. This recently happened to me, and bizarrely they wouldn’t tell me what’s actually going on on my account because of not being able to verify me. (They were also immediately asking for personal information on the outbound call, which apparently really was from them.)

Financial companies, the government, ... I always try to bother to raise the issue afterwards, but (not that I think my comments alone would do anything) so far nothing changed that I've taken issue with, I don't think. A big one I'm aware of many others complaining about in the industry is local governments in the UK soliciting elector details via 'householdresponse.com/ ' in a completely indistinguishable from phis…

Ha, this reminds me of driver licences in Australia. So at this point almost everyones licence has been leaked multiple times (and just having the details used to be enough to open a bank account online, not sure if this is still the case).

I received an email from my state’s RTA, saying they were adding 2-factor authentication to licences. Great! I assumed this might be an oauth type scenario, or maybe even just email.

Nope. The “second” factor is a different number printed on the licence. Surely this communication had to go through multiple departments, get vetted for accuracy. Yet no one picked up that this isn’t multi factor authentication.

Its only purpose is to make it easier for them to issue a new licence _after_ you’ve been defrauded out of all your money, because most states refuse to issue people with new licence numbers. It does nothing more than fix an incompetence in their system/process. Yet it was marketed as some kind of security breakthrough, as if it would add protection to your licence.

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

#224

Post by devjab »

hn_throwaway_99 wrote: post #111
devjab wrote: post #105

Earlier quoted context omitted.

I’ve done 6 different versions of “security training” as well as “GDPR training” over the past few years. I think they are mostly tools to drain company money and wasting time. About the only thing I remember from any of it is when I got some GDPR answer wrong because I didn’t resize your shoe size was personal information and it made me laugh that I had failed the whatever quiz right after I had been GDPR certified…

To emphasize, I 100% agree with you. I'm not arguing for more security training, I'm arguing for less . "Hang up, look up, call back". That's it. Get rid of pretty much all other "security training", which is just a box ticking exercise for most people anyway. I also agree with the comment about better security tools, but that's why I think "hang up, look up, call back" is still important, because it teaches people t…

Then I guess we agree! My mantra is to just never click on any links. Even when I know they aren’t phishing I don’t click on them.

Of course that’s probably easier for a programmer than most other employees. I’m notoriously hard to reach unless it’s through a user story on our board that’s first been vetted by a PO. Something you probably can’t get away with if you’re not privileged enough by being in an in-demand role where they can’t just replace you by someone more compliant. I do try not to be an asshole about it, but we have soooooo many fake phishing mails and calls from our cyber awareness training that it’s just gotten to the point where it’s almost impossible to get trapped by one unless you ignore things until someone shows up in person. Luckily one of my privacy adding in FireFox prevented me from getting caught when I actually did click one of the training links on one of those famous Thursday afternoons. So I still don’t have the “you’ve clicked a phishing link” achievement… which I’m still not sure why is there, because I sort of want it now that it is, and eventually that urge is going to win.

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

#225

Post by fragmede »

solatic wrote: post #219
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 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.

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

#227

Post by Thorrez »

I don't think it's really accurate to describe it as not MFA. The attacker phished a password and 2 TOTP codes. So the attacker phished 3FA.

So yes, Google Authenticator sync made the security worse, but it didn't downgrade the security from MFA to non-MFA. And even if the sync was off, the TOTP codes in Google Authenticator could have been phished as well, so Google Authenticator can't be blamed so heavily, because the attack could have been done without it.

Disclosure: I work at Google but not on Google Authenticator.

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

#228

Post by netik »

luma wrote: post #78
miki123211 wrote: post #53

Earlier quoted context omitted.

The problem with Fido (and other such solutions, including smartphone-based passkeys) is that they make things extremely hard if you're poor / homeless / in an unsafe / violent family situation and therefore change devices often. It's mostly a non-issue for Silicon Valley tech employees working solely on their corporate laptops, and U2F is perfect for that use-case, but these concerns make MFA a non-starter for the w…

Biometrics aren’t a great key because they cannot generally be revoked. This isn’t a privacy concern, it’s a security problem. You leave your fingerprints nearly everywhere you go, and they only need to be compromised once and then can never be used again. At best, you can repeat this process a sum total of 10 times without taking your shoes off to login.

I’ve always referred to biometrics as a “non revokable username” and not a “password.”

100% agree with you here.

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

#229

Post by netik »

toast0 wrote: post #195
andersa wrote: post #150

Earlier quoted context omitted.

They could do what Authy does. Codes are backed up to the cloud, so you're not completely fucked if the phone is stolen. But the backup is encrypted, and to access it on a replacement device you must enter the backup password.

That relies on someone remembering their backup password that they probably don't use often.

Authy makes the user enter this on a periodic basis to refresh their memory, which is a good thing imho

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

#230

Post by richrichardsson »

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…

> unfortunately did provide the attacker one additional multi-factor authentication (MFA) code

How is this Google's fault?

Which rock was this employee living under to not have understood you NEVER give an OTP code to anyone?

Post reply on HN