Live data from Hacker News

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

retool.com

61–70 of 287 posts

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

#62

Are the claims of deepfake and intimate knowledge of procedures based of the sole testimony of the employee who oopsed terribly? This is a novelisation of an events Retool needs to revise the basic security posture. There is no point in complicated technology if the warden just gives the key away.

> Retool needs to revise the basic security posture. Couldn't agree more. TBH I thought this post was an exercise in blame shifting, trying to blame Google. > 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. The fact that access to a Google account immediately gave access to a…

> Google Workspace makes it very easy to set up "Advanced Protection" on accounts, in which case it requires using a hardware key as a second factor, instead of a phishable security code.

This isn't immediately actionable for every company. I agree Retool should have hardware keys given their business, but at my company with 170 users we just haven't gotten around to figuring out the distribution and adoption of hardware keys internationally. We're also a Google Workspace customer. I think it's stupid for a company like Google, the company designing these widely used security apps for millions of users, to allow for cloud syncing without allowing administrators the ability to simply turn off the feature on a managed account. Google Workspace actually lacks a lot of granular security features, something I wish they did better.

What is a company like mine meant to do here to counter this problem?

edit: changed "viable" for "immediately actionable". It's easy for Google to change their apps. Not for every company to change their practices.

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

#63

Question for security folks out there: So often I see these kinds of phishing attacks that have hugely negative consequences (see the MGM Resorts post earlier today), and the main problem is that just one relatively junior employee who falls for a targeted phishing attack can bring down the whole system. Is anyone aware of systems that essentially require multiple logins from different users when accessing sensitive…

[deleted]

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

#64
post #22

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

> 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 the design decision is questionable, the gain in security from people not constantly losing their phone probably outweighs for the average person the loss of security of it all being in a cloud account (as google cloud for most people is probably one of their most well secured account)

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

#65

Question for security folks out there: So often I see these kinds of phishing attacks that have hugely negative consequences (see the MGM Resorts post earlier today), and the main problem is that just one relatively junior employee who falls for a targeted phishing attack can bring down the whole system. Is anyone aware of systems that essentially require multiple logins from different users when accessing sensitive…

You're looking for quorums, or key splits. They aren't super common. You see them with some HSMs (need M of N persons to perform X action).

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

#66

Earlier quoted context omitted.

Well, push based 2fa with "select this number on your 2fa device" helps prevent some vectors. Simple totp doesn't do that. "Never give your totp or one time code over the phone" is good advice. "Never give info to someone who called you, call them back on the official number" is another. This is user error at this point.

I disagree. Specially again that companies are centralizing on a couple 2FA companies (like Okta from TFA), this is just ripe for phishing. Okta itself is terrible at this; they don't consistently use the okta.com domain, so users are at a loss and have basically no protection against impersonators.

For okta, if it is set up properly, the user should get push notifications. And in that push notification is a number they need to select to validate the push.

This eliminates credential phishing and "notification exhaustion" where a user just clicks "ok" on an auth request by a bad actor.

As much as I advocate for non cloud services, what okta provides is very secure.

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

#67
post #3

Earlier quoted context omitted.

inside job?

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.

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

#68

Are the claims of deepfake and intimate knowledge of procedures based of the sole testimony of the employee who oopsed terribly? This is a novelisation of an events Retool needs to revise the basic security posture. There is no point in complicated technology if the warden just gives the key away.

[dead]

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

#69
post #24

Earlier quoted context omitted.

> 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?

Not all websites offer them. Hell, no bank I use (several large and several regional) support generic totp. Some have sms, one has Symantec VIP, proprietary and not redundant. Edit: since I'm posting too fast according to HN, even though I haven't posted in an hour, I'll say it here. Symantec is totp but You cannot back up your secrets and you cannot have backup codes.

Symantec VIP is TOTP under the hood.

https://github.com/dlenski/python-vipaccess

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

#70

Question for security folks out there: So often I see these kinds of phishing attacks that have hugely negative consequences (see the MGM Resorts post earlier today), and the main problem is that just one relatively junior employee who falls for a targeted phishing attack can bring down the whole system. Is anyone aware of systems that essentially require multiple logins from different users when accessing sensitive…

i wonder on this too if people really use shamir secret sharing as part of some security compliance
Post reply on HN