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

241–250 of 287 posts

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

#241

Post by crabbone »

odux wrote: post #181
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…

Wait, what? MFA - multi factor authentication- has existed long before Google was founded. RSA Securid tokens were introduced in the 1980s or so. MFA is a easy and good way to prevent hostile account takeovers. Especially with the amount of data breaches, one time passwords are way more secure than memorized “static” passwords. SMS based two factor is the one Google pushed. Even Google recommends other ways of MFA th…

MFA in its current form owes its existence to a lawsuit filed against Google being a monopoly on Android when packaging and selling advertisement data to ad campaign management companies.

It's not about being able to tie your phone number to your name. It's about being able to tie your browsing, purchasing, and other behavior history to an id that doesn't change much.

Google by itself doesn't run ad campaigns. It sort of has API to design a campaign yourself... but that's super ineffective. There are multiple companies who manage ad campaigns which run on Google. In order to be effective they need to have some predictive power over user's future browsing, purchasing etc. choices. Being able to consistently identify the user (and tie that to their history) is the most valuable ad-related info anyone can sell.

Whatever existed in the 80s has nothing to do with MFA is today. Today it's a scam that helps big tech companies who want to be an advertisement platform to harvest and to catalogue data helping advertisers predict user behavior. All it does to end users is inconvenience and less security. All it does to IT is an extra headache and more procedures that may potentially go wrong.

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

#242

Post by crabbone »

acegopher wrote: post #175
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 use 1Password's authenticator, so no-one needs my phone number, and I don't have to worry about losing my phone, as there is a Linux CLI, a browser extension, etc.

You forgot to add: for now.

There is no genuine interest on the other side to provide you with better security. There is no genuine interest on the other side to make your life easier / to care about your privacy. You are allowed to opt out through a complicated mechanism because the provider needs high volume of users. As time goes, either the law will catch up to the provider and will make them make mandatory exceptions to this nonsense, or they will just exploit you whichever way they can.

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

#243

Post by solatic »

fragmede wrote: post #225
solatic wrote: post #219

Earlier quoted context omitted.

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.

Yubico's U2F security key (good for FIDO2, WebAuthn, etc.) is $25, each member of your organization needs only 1 key (if they lose their key, they can get another one from IT, which can remove the old key and enroll the new one for them), with a handful of IT personnel possibly having more than 1 key for backup (this is less necessary when a group of IT holds admin permissions, as they serve as key backups for each other). $25/key amortizes out to well under $1/month considering that keys will last for years and can be transferred from one employee to the next when an employee leaves the company, and is of course usable for any vendor that supports hardware keys.

Much, much cheaper than $21/user/month for GitHub Enterprise. I'm not sure what universe you live in where buying hardware keys is expensive compared to Enterprise licensing?

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

#244

Post by itsoktocry »

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

This is a policy I've implemented as well, both for myself and loved ones: don't provide any information to unverified incoming calls. Zero.

Sometimes I'll get some kind of sales call, which I may even be interested in. I'll say, proceed with the pitch to which they'll reply "first we need to confirm your identify". Then I refuse: you called me. Why do you need me to provide private information to confirm my identity?

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

#245

Post by raybb »

itsoktocry wrote: post #244
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 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. This is a policy I've implemented as well, both for myself and loved ones: don't provide any information to unverified incoming calls. Zero. Sometimes I'll get some kind of sales call, which I may even be interested in. I'll say, proceed with the p…

What does unverified mean in this case?

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

#246

Post by quickthrower2 »

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 is where some kind of chaos monkey might be good. Imagine something that randomly slacks from one human account to another asking for passwords and then the receiver has to press a "suspect message" button as a form of ongoing awareness training.

As part of that a genuine ask for a password would get the same response, and perhaps the button sends a nice message like "Looks like you have asked for a password. We get it, sometimes you need to get the job done, but please try to avoid this as it can make us insecure. Please read our security policy document here."

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

#247

Post by wink »

yieldcrv wrote: post #92
luma wrote: post #82

Earlier quoted context omitted.

Fully agreed, saying a deepfaked voice was involved without hard proof is deflecting blame by way of claiming magic was involved.

I think its right to be skeptical, but its also easy to do this if you’ve identified the employee to train on the voice of. You could even call them and get them to talk for a few minutes if you couldnt find their instagram.

Instagram for sound? You must know some people that use it very different than the people I know (if they're even still there).

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

#248

Post by raverbashing »

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…

True, why are people so eager to pick up the phone.

The millenials are right in not picking up the phone

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

#249

Post by raverbashing »

nanidin wrote: post #180
Terretta wrote: post #174

Earlier quoted context omitted.

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

Credit card fraud departments are generally good about this.

Are they? Are they still asking about "mother's maiden name"?!

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

#250

Post by j0057 »

TOTP: better than nothing, but not a lot better. It depends on the human being infallible. U2F doesn't, and would have worked here to prevent the takeover and the need for blaming the employee for not being infallible, but hey, at least less than $50 of hardware costs was saved by the employer!
Post reply on HN