When MFA isn't MFA, or how we got phished (opens in new tab)

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

Anecdotally, I seem to have had the opposite experience. I've been doing this for at least 15 years, and never had a negative reaction. With bank, credit card, or finance-related companies, they seem to understand immediately. With other callers I've gotten awkward pauses, but ultimately they were politely accommodating or at least understanding that some issue would have to be processed through other channels or postponed.

However, I don't have strict requirements. When a simple callback to the support line on the card, bill, or invoice doesn't suffice--and more often than not it does, where any support agent can field the return call by pulling up the account notes--all I ask for at most is an extension or name that I can use when calling through a published number. I'll do all the leg work, and am actually a little more suspicious when given a specific number over the phone to then verify. Only in a few cases did I have to really dig deep into a website for a published number through which I could easily reach them. In most cases it suffices to call through a relatively well attested support number found in multiple pages or places[1].

I'm relatively confident that every American's Social Security number (not to mention DoB, home address, etc) exists in at least one black market database, so my only real practical concern is avoiding scammers who can't purchase the data at [black] market price, which means they're not very sophisticated. A callback to a published phone number for an otherwise trusted entity that I already do business with suffices, IMO. And if I'm not already doing business with them, or if they have no legitimate reason to know something, they're not getting anything, period.

[1] I may have even once used archive.org to verify I wasn't pulling the number off a recently hacked page, as it was particularly off the beaten path and a direct line to the department--two qualities that deserve heightened scrutiny by my estimation.

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.

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.

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 the scammers, which was of course controlled by them and not the bank.

I don't think most people who get scammed this way pause to say "oh, this might be someone stealing my credit card number", then disregard that thought because it's too much of a pain to call back on an official line. Instead I think they don't question the situation at all, or the scammer has enough information to sound sufficiently authoritative. Most non-technical people I've talked to about this are pretty scared of getting scammed, but tell me the thought never crossed their mind they could call back on a trusted number.

I like the "hang up, call back" approach because it takes individual judgment out of the equation: you're not trying to evaluate in real time whether the call is legit, or whether whatever you're being asked to share is actually sensitive. That's the vulnerable area in our brains that scammers exploit.

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.

Great point. But it could be easily solved with something like: “Call the number on the back of your credit card. Push *5 and when prompted enter your credit card number and you will be immediately connected back to my line”

If my bank cold calls me, I can say "I just need to verify the legitimacy of your call, so send me your direct number in the online bank app, and I'll call you". It works every time, but it also works because all the employees have a direct number.

Normally we just write message back and forth in the banking app, and if we talk it's an online meeting with video. Only for large business I go to the physical site.

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 bought a plumbing valve from has an office somewhere with a secretary that gets a phone call maybe three times a month from customers looking to resolve issues - and Amazon has mostly centralized support for small sellers and has lines you can call to resolve any disputes you have which may forward you to the original sale party but often just resolve the issue directly.

Honestly, the worst experiences are usually with large companies that funnel all customers into massive phone centers - I've probably lost the better part of a week to Comcast over my lifetime.

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 increasingly clear that the initial call had been a high quality scam, and not in fact a real person from the bank.

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 the idiots writing the government standards on these fraud departments before we get jail time for the idiots running these fraud departments before it gets better.

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/<councilname>' in a completely indistinguishable from phishing sort of way.

(They send you a single letter directing you to that address with 'security code part 1' and '2' in the same letter, along with inherently your postcode which is the only other identifier requested. It's an awful combination of security theatre and miseducation that scammy phishing techniques look legit.)

That's the big problem, isn't it? People think it's okay to give out information on an incoming call because often it is really okay. If it were unreliable 99% of the time, phishers would not use this method as an attack vector.

What does unverified mean in this case?

I've stopped listening to people. I limit myself to talking at them. The upside is that I'm never fooled. The downside is that so far as I can tell half the world hates me and the other half think I'm a lunatic.

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.

Thanks for all this insight, this is why HN rules. What is your impression of law enforcement, everyone claims to reach out after an attack, but I've never seen follow up of sucessful law enforcement activity resulting in arrests or prosecution. Thanks again.

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

Does that mean they have audio of the call?

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.

Thanks for the reply! What's expecting one.

Since you might have you delete the reply anyway, can I get a candid answer on why hardware 2FA tokens weren't a part of the default workflow before the incident? Was it concerns about the cost, the recovery modes, or was it just the trust in the existing approach?

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.

It's also a reasonable defence against naive keylogging techniques - including shoulder-surfing either directly or eg via security cameras. In some places this can be a pretty big threat.

Well all Google needed to do to make it at least a little harder is to encrypt the backup with a password at least.

The user can still put in an insecure password but uploading all your 2FA tokens to your primary email unencrypted is basically willingly putting all your eggs in one basket.

TOTP is helpful when you don’t fully trust the input process. If rogue javascript is grabbing creds from your page, or the client has a keylogger they don’t know about, TOTP can help.

great insight:

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

Why is no one talking about this?

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 wider population. We could neatly sidestep all of these issues with cloud-based fingerprint readers, but the privacy advocates won't ever let that happen.

A number of sites I've signed up for recently have required TOTP to be setup, but did not provide back up codes at the same time. There's a lot of iffy implementations out there.

With Google Authenticator some years ago it wasn't even possible to restore your codes even if you had a local backup of the device. I'm not sure if that still is the case today but it was a common issue which we saw at our service desk before we switched to a different solution.

After initially thinking it was a good idea, I've come to disagree pretty strongly with the idea of phish baiting employees. Telling employees not to click suspicious links is fine, but taking a step further to constantly "testing" them feels like it's placing an unfair burden on the employee. As this attack makes clear, well done targeted phishing can be pretty effective and hard for every employee to detect (and you need every employee to detect it).

Company security should be based on the assumption that someone will click a phishing link and make that not a catastrophic event rather than trying to make employees worried to ever click on anything. And has been pointed out, that seems a likely result of that sort of testing. If I get put in a penalty box for clicking on fake links from HR or IT, I'm probably going to stop clicking on real ones as well, which doesn't seem like a desirable outcome.

The workaround I've seen is to issue a user two 2FAs keys, one for regular use and one to store securely as a backup. If they lose their primary key, they have the backup until a new backup can be sent to them. Using a backup may prompt partial or total restriction until a security check can be done. If they lose both, yes, there needs to be some kind of a reauth. In workplace context like this it's straightforward to design a high-quality reauth procedure.

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.

You live in a funny alternate reality. You should consider what it might be like to live in one where everyone else isn't dumber than you.

I will tell you a truth: People who think they're smarter than everyone else are generally missing important context or information.

Not OP, but I store my TOTP secrets along with all my other passwords in a KeePass database and sync the encrypted database to my devices with Dropbox. All the clients I use to open a KeePass database can generate TOTP codes from the secrets at this point, so I don't use a dedicated TOTP app like Google Authenticator or Authy anymore.

Not multifactor anymore, but also not vulnerable to catastrophic phone destruction or Google account banning. It is what it is.

After the sync, you have exactly two devices that you can use to answer the MFA challenge, instead of one. It's a backup.

The ineffectiveness of "security training" is precisely why TOTP is on its way out - you couldn't even train Google employees to avoid getting compromised.

But aside from beating employees over the head with it, how many companies actually operate in a way that encourages and reinforces such an approach? I'd bet it's not many, and honestly if it's a non-zero number I'd be at least a bit surprised.

You can have all the security training in the world, but every time IT or HR or whoever legitimately reaches out to an employee, especially when it's not based on something initiated by the employee, the company is training exactly the opposite behavior Krebs is suggesting. Hanging up and calling back will likely at minimum annoy the caller and inconvenience the employee. Is the company culture accepting of that, or even better are company policies and systems designed to avoid such a scenario? If a C-suite person calls you asking for some information and you hang up and call them back, are they going to congratulate you on how diligently you are following your security training?

You're not wrong that the Krebs advice would help prevent most phishing, but I'd argue it has to be an idea you design your company around, not just a matter of security training. Otherwise you're putting the burden on employees to compensate for an insecure company, often at their own cost.

This fails to satisfy one of the core lessons here: trust nothing, not even your own training and culture.

They just have to catch someone half-awake, or already very stressed out, or otherwise impaired once.

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 by some other training tool.

If we look at the actual data, we have seen a reduction in employees who fall for phishing emails. Unfortunately we can’t really tell if it’s the training or if it’s the company story about all those million that got transferred out of the company when someone fell for a CEO phishing scam. I’m inclined to think it’s the latter considering how many people you can witness having the training videos run without sound (or anyone paying attention) when you walk around on the days of a new video.

The only way to really combat this isn’t with training and awareness it’s with better security tools. People are going to do stupid things when they are stressed out and it’s Thursday afternoon, so it’s better to make sure they at least need a MFA factor that can’t be hacked as easily as SMS, MFA spamming and so on.

Most places don't host TOTP auth servers because generally you want to bundle up the whole authn/authz package. Since you need your MFA flow to be connected to your primary auth flow, having one provider for one and then self-hosting the other is generally not smooth or easy.

Push notifications are also, in my experience, a massive pain (both in terms of the user flow where you have to pull out your phone, and in terms of running infra that's wired up to send pushes to whatever device types your users have). Notably, now you need a plan for users that picked a weird smartphone (or don't have a smartphone).

The better option is to go for passwordless auth, which you could self-host with something like Authentik or Keycloak, and then it handles the full auth flow.

FIDO2

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

Anything's possible, but the simplest explanation (per Occam's razor) is just that the employee was fooled.

Is it plausible that if a good social engineer cold-called a bunch of employees, they'd eventually get one to reveal some info? Yes, it happens quite frequently.

So any suggestion that it was an inside job, or used deep fakes, or something like that would require additional evidence.

Kevin Mitnick's "The Art of Deception" covers this extensively. The first few calls to employees wouldn't be attempts to actually get the secret info, it'd be to get inside lingo so that future calls would sound like they were from the inside.

For example, the article says the caller was familiar with the floor plan of the office.

The first call might be something like "Hey, I'm a new employee. Where are the IT staff, are they on our floor?" - they might learn "What do you mean, everyone's on the 2nd floor, we don't have any other floors. IT are on the other side of the elevators from us."

They hang up, and now with their next call they can pretend to be someone from IT and say something about the floor plan to sound more convincing.

how's that Zero Trust architecture working out for everyone ?

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

Hi, I'm sorry you felt that way. "Shifting blame to Google" is absolutely not our intention, and if you have any recommendations on how to make the blog post more clear, please do let me know. (We're happy to change it so it reads less like that.)

I do agree that we should start using hardware keys (which we started last week).

The goal of this blog post was to make clear to others that Google Authenticator (through the default onboarding flow) syncs MFA codes to the cloud. This is unexpected (hence the title, "When MFA isn't MFA"), and something we think more people should be aware of.

It was also a bit weird how they kept emphasizing how their on-prem installations were not affected, as if that lessens the severity somehow. It's like duh, that's the whole point of on-prem deployments.

That is more plausible. But the embellishment about the phisher knowing the layout of the office etc makes me think it was just straight up an inside job, with the employee willingly handing over the OTP and trying to cover their tracks.

This would almost certainly be it. Calling someone to record them and using their voice later to impersonate them was done even before deep-fake voices were a concept. With the tools available now, even a short call + the grainy connection of a phone voice line would be more than enough to make a simulated voice work.

I'm already cautious about answering calls from unknown numbers. This could be a good reason to be even more cautious.

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.

Google were sued because they were selling to advertisers information about Android users that other advertising platforms couldn't possibly had. Advertisement data s.a. user preferences, their history of clicking on ads, browsing history etc would all be organized by the id derived from Android device. Once the court decided they cannot do that, and users should opt in to be tracked, they promptly created MFA that relied on collecting data about physical devices. Which they then again used to sell advertisement data.

The whole point of this exercise is not to enhance security, but to have an edge as an advertisement platform. If today you can trick the system into not using a phone, it's a temporary thing. The more users join, the tighter will be the system's grip on each individual user, and the "privilege" of not divulging your phone number will be taken away.

Google did this before with e-mail access for example, multiple times, actually. Remember how GoogleTalk used Jabber? -- Not having to use a proprietary chat protocol was a feature that made more users join. As soon as there were enough users, they replaced GoogleTalk with Hangouts or w/e it's called.

GMail used to provide standard SMTP / IMAP access, but they continuously undermined all clients other than Google's. Started with removing POP access. Then requiring mandatory TLS. Then requiring a bunch of nonsense "trusted application registration". Finally, this feature is now behind MFA, which makes it useless anywhere outside Google's Web client / Android app etc. All of this was delivered as a "security improvements", while giving no tangible security benefits. It was a move to undermine competition.

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.

Google repeatedly sends the 2fa to my phone even though I have an authenticator app set up for it. Even if I use the app, it still asks me to authenticate their own thing on my phone. So I just gave up and use that all the time now.

> U2F/FIDO etc keys are only supported by a subset of websites.

But a growing number. https://passkeys.directory/ is a good place to check.

Ask for it. MFA via SMS/email/etc was not very common 10 years ago, but it is now. That's due in part to people asking for it.

But they're not application level protocol agnostic. Based on my understanding, they require use of HTTP. If I want to get MFA using an email client communicating via SMTP and IMAP, then the email client needs to be able to interact with the HTTP API.

Ahh, thanks and apologies for not re-reading before asking.

That is indeed interesting; keep the con going a bit longer to get a proper foothold.

Really, really appreciate you sending this! I will dig in but this seems to be exactly what I was asking about/looking for. I'm always really curious why the big native cloud platforms don't support this kind of authentication natively.

not good with acronyms, what is hsm here?

Which is funny because the 2nd factor is "something I have", which means if you don't "have it" then you can ever complete the 2nd factor. This ultimately means the 2nd factor, when you're phone goes swimming, is ultimately your printed codes.

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.

Well that's even worse isn't it?

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

A better way to fix this is to have multiple ways to log in. Printed backup codes in your safe with your personal papers and/or a Yubikey on your keychain. This works for Google and Github, at least.

Passkey syncing is more convenient, though, and probably an improvement on what most people do.

If you can backup a key it is not MFA. It just a second password and not another factor. The solution to having your phone smashed is to have multiple "something you have", so you have a backup.

Google Authenticator was I believe the first available TOTP app, and is by far the most popular. It used to be open source and have no connection to your Google account. Many people installed it years ago when they first set up MFA, and have just been adding stuff to it ever since because it's easy and it works. Even for technical users who understand how TOTP works, there is no obvious reason it appears unsafe to put all your tokens in the app (until you read this article).

Look at the MFA help page for any website you use. One of the first sentences is probably something like "First you'll need to install a TOTP app on your phone, such as Google Authenticator or Authy..."

It really did used to be the best option. For example, see this comment from 10 years ago when Authy first launched:

> The Google Authenticator app is great. I recently got (TOTP) 2-factor auth for an IRC bot going with Google Authenticator; took about 5 minutes to code it up and set it up. It doesn't use any sort of 3rd party service, just the application running locally on my phone. TOTP/HOTP is dead simple and, with the open source Google Authenticator app, great for the end user.

- https://news.ycombinator.com/item?id=6137051

Yeah, just add some twangy dropouts like a poor cell connection has.

Making a meme is nothing like an interactive telephone conversation.

It's not that it's impossible, but it's not trivial either. But mainly, it's just unnecessary.

If the user is not fooled by a well crafted phishing, by doing the most trivial countermeasures such as calling back, they are not going to be fooled by a deepfake. In practice work on phishing is mostly better spent elsewhere. So while we shouldn't dismiss it completely, it's clearly not the case with a smallish company with limited economic value, so very unlikely the case here.

There has been a handful of highly profile media cases involving deepfake. None of which has held up on further investigation. It is understandable, nobody wants to be known as the one who didn't recognize his own kid on the phone, but the truth is more simple and actually helps us when designing countermeasures.

I blame SAML and any other federated login being an "enterprise only" feature on most platforms.

So users get used to sharing passwords between multiple accounts and no centralised authority for login. This causes the "hey what's your password? I need to quickly fix this thing" culture in smaller companies which should never be a thing in the first place.

If users knew the IT department would never need their passwords and 2FA codes they would never give them out, the reason they give them out is because at some point in the past that was a learned behaviour.

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.