Ultimately what this shows is that two factor authentication with either TOTP (aka Google Authenticator) or SMS is not ideal. It makes phishing harder for the attacker, but it does not prevent it.
Unfortunately he fails to mention that there is a way to do 2fa that does prevent phishing: Hardware tokens with the webauthn protocol.
I disagree. TOTP-based 2FA is leaps-and-bounds more secure than SMS based 2FA and will stop nearly all attempts to access your account.
The fault here lies with victims answering a prompt to enter their 2FA out of the blue. Just as with passwords and other such info, the bank will never request it for no reason.
A hardware token using webauthn protocol is most secure though, yes.
The fault with phishing _always_ lies with the victim, by this logic.
Put differently: if you assume the user to be infallible, there's very little reason to use 2FA of any kind. (Don't believe me? Describe to me a threat which applies to an infallible password-only user which is mitigated by non-FIDO2 second factors.)
I leave my work desk to grab a coffee. An attacker adds a hardware keylogger between my keyboard and computer. When I come back 5 minutes later I don’t sweep for any hardware modifications. Now they have my password.
This threat model is orders of magnitude less likely than something like phishing. It is not scalable for attackers and simply doesn't work for anybody who works from home or works in a location with meaningful physical security.
It also isn't defeated by 2FA, since they've physically installed something on your machine to detect your keypresses. They just capture your password and the sms code.
The post asked to “Describe to me a threat which applies to an infallible password-only user which is mitigated by non-FIDO2 second factors.” Defense in depth is absolutely a thing. Now does your grandfather need this level of security? Probably not. But that doesn’t mean multi-factor is worthless.
You've installed a physical device. Just have it interfere with the actual code typed to the 2fa page so the target's login fails and automate the login with the correct code.
Sure, I guess. I would tend to argue that with hardware access they can do a number of things, though:
- They can install a wifi-enabled* keylogger that exfiltrates your OTP. Yes, they have to use the OTP before you do, but that seems solvable to me--just program the keylogger to transpose one of the six characters that comes after your (now known) password.
- They steal your computer. Are you using FDE? If not, your cookies are sitting there on disk waiting for them.
- They...steal your phone next time you forget it at your desk. ;)
Are there scenarios where TOTP can protect against a non-phishing attack? Yeah, I can construct one if I really have to. (I think you're thinking too locally; my top argument for TOTP would be that I can rarely be sure the identity provider has implemented reasonable quotas against password brute-forcing--and who knows how well they secure things like server logs against rogue insiders?)
But if you tell me you use TOTP because you're afraid of a local attacker plugging in a keylogger--and not because of phishing--I think your priorities are out of whack. :)
WebAuthn saves granny though. Because it's so easy that granny can't get confused. The best way forward under WebAuthn is to have her physically send them her Security Key.
Now, granny may not be down with the latest Tik Tok trends, but she has seen keys before, and the analogy is strong - so I think she can get this right.
To be fair, scammers have been successful with scams that involve an actual bike courier (presumably the scammer or a friend) coming to pick up your bank card, but that at least feels a bit reasonable because it does say the card remains property of the bank, so, sure, have your card back. And I'm also guessing this is a much higher friction scam than the average "Phone support in India" setup. I reckon scam dozens of people for their card this way and somewhere around the 100 victims mark the guy opening the door to your courier has a baseball bat, or worse, and your courier has a bad day.
> The fault here lies with victims answering a prompt
> to enter their 2FA out of the blue.
Go wish 10 random people happy birthday. For some people such a greeting is relevant for one day only. For others, a week. For some people, especially if the don't recognize you and think that "it's been a long time" a whole month is valid.
If one is using a dozen services that auth with 2Fa and needs to log in once per day, that's a lot of windows of opportunity. Multiply that by 86,400 numbers phished that day.
We've spent years and years and years trying to train people to resist phishing. It doesn't work. Even actual literal security professionals fall for it. If you use a thing with such common known failure modes, it is your responsibility for using that thing.
Phishing is enormously more common than sim-swapping because, as described in TFA, it can be fully automated. Going from SMS to TOTP fixes a rare attack but does not fix a common attack.
So what other options do we have available? We have tried client certificates, hardware tokens, biometrics and a tonne of heuristics. None of these could do much to stop an attack when the user is cooperating with the scammer.
Webauthn works. You cannot sign a message for the wrong origin. The core problem here is that everybody needs access to some sort of hardware to do this and they need systems to handle the inevitable loss of that hardware.
Literally Windows and MacOS has this built-in. But you’re right, the hard part is losing the token or it breaking. I slammed one Yubikey in a door, breaking it in half. I’m on my backup but I still find services where I didn’t enroll the backup and have to go through a lengthy process to regain access to my account (or create a new one).
Hardware tokens and biometrics are better because it makes it harder for the scammer to describe a plausible scenario to intercept the authentication.
In one of the linked articles the scammers pretended to send a one-time token and asked the victim to read it back. This is the same process my top-10 US-based bank uses, so it wouldn’t necessarily raise any red flags.
The data does not seem to support this. Yes, spear phishing is even more effective. But oodles and oodles and oodles of exercises demonstrate that people, even experts, fall for phishing.
Experts fall for phishing because many businesses, including and especially financial institutions (PayPal and eBay are easily some of the worst offenders here), make it essentially impossible to tell phishing from their "legit" mails.
It does. This is why every service should be making active plans to push in this direction. We've struggled with this problem for ages and it is now completely solved.
Does it really though? I love Webauthn. It is so much better than passwords. But I don't think it means the end of phishing. Phishers will evolve too and find new tricks. Just like they did here with OTP interception bots.
For example a phishing site could trick me into authenticating into a fake site, and give them a session at the real site as a result. They won't have my actual credentials but they could have a session which is enough to do a lot of damage.
I don't think Webauthn guarantees that the site I'm authenticating to is the site I'm supposed to (though I may be wrong here, I didn't read into it too deeply). As far as I know it still relies on TLS for that, and regular phishing and typosquatting show that this is not airtight. It would be great if the authentication worked both ways, the server would authenticate to the client as well as it does to the server.
It does raise a few other questions too. If every site uses Webauthn, I will have to update every site when I get a new yubikey. That's going to be a PITA.
A solution for that would be using an identity service.. Like "Sign in with Google". But I would never trust a commercial service like Google, Facebook, Microsoft for this. It would have to be something open and privacy-safe.
> For example a phishing site could trick me into authenticating into a fake site, and give them a session at the real site as a result.
The fake site needs to be hosted somewhere, presumably not on the same origin as the real site. As such, your key will be unable to sign a message for the phishing site regardless of how hard you try.
This is the core difference with SMS/TOTP. With those models nothing stops you from handing the material over to a site on a different origin and letting them reflect that material to the target site. With webauthn, the thing you hand the phishing site is useless for authenticating on the target site.
> I don't think Webauthn guarantees that the site I'm authenticating to is the site I'm supposed to (though I may be wrong here, I didn't read into it too deeply). As far as I know it still relies on TLS for that, and regular phishing and typosquatting show that this is not airtight.
WebAuthn needs the DNS name of the site to exactly match. This isn't for humans, who think 1 and I are pretty similar, it's for a machine, which thinks they're different. Phishing and typosquatting don't get you google.example they get your google.comsecurityupdatelogin.example or goggle.example which do not match. Now, in principle you could attack the Ten Blessed Methods to get yourself a real, legitimate (albeit fraudulently obtained) certificate for the exact DNS name of a real popular site, but that's not easy, and indeed making it more difficult is a continuing focus of Web PKI work. Also, defenders can make it arbitrarily harder if they put work in.
I never tired of explaining the clever trick that makes this possible, so here goes (for the easy case of a cheap Security Key, something like an iPhone can do fancier tricks with more complicated explanations)
When you enroll at some.example, your Security Key is told we're enrolling at SHA256("some.example"). A button flashes and you push it. The Security Key picks a completely random public/private key pair. It uses the private key to sign a document, "Hello, I am this Security Key, I checked a human was present" and it encrypts the private key with its own symmetric key and with that SHA256("some.example") parameter as "Extra data" in an AEAD (Authenticated Encryption, Extra Data) cipher to produce a large opaque blob it will claim is a "random identifier". It sends the public key, the "random identifier" and the signed message back to your web browser. You are enrolled.
When you come back to the site, the site says oh, your account requires a Security Key, prove you still have it. It sends one or more of those "random identifiers" corresponding to enrolled Security Keys. Your browser talks to any Security Keys plugged in, hey, I'm at SHA256("some.example") and it asked if anybody can prove I'm still some-huge-identifier ?
Your Security Key tries to decrypt some-huge-identifier using its symmetric key, and the Extra Data SHA256("some.example"). Maybe it gets a success and a private key. The little button flashes and you push it. In this case it can sign a message using the private key, "Yes, I'm still me, I checked a human was present"
But, if anything goes wrong, that decryption will fail. If this is some-other.example, SHA256("some-other.example") won't match and decryption fails. If the site picks random gibberish instead of your identifier, decryption fails. If you plugged in the wrong Security Key, decryption fails.
You are unable to even try to authenticate to the wrong site. And if they enroll you which they can do, now they've got useless credentials for you to sign into their site that are unrelated to the credentials on other sites. They're even deliberately not correlated and they aren't even wasting space on your Security Key, the Security Key (this is why the trick was so clever) doesn't store anything to make all this work! All the storage is in the Relying Parties, and it's all storage of public data that's harmless when inevitably crooks steal it.
Ah thanks for clarifying. I didn't know that Webauthn did that. I had planned to read up in it in detail but at work it has been ruled out for implementation for the next months so it didn't have priority :)
I really appreciate the breakdown of how it works! I agree this makes phishing almost impossible (at least without obtaining a valid cert which is in itself really hard for a non state actor)
In my experience, banks and other online institutions have spent years training their customers to fall for phishing attempts by sending legit emails with embedded links. People take it for granted that emails coming into their inbox that contain links to login pages really are from their bank, because that's how their bank behaves normally.
I hadn't ever thought about this but you're right. Best practice for sensitive services like banks should be to have no links at all in emails. I don't think that's likely to change though.
Even worse, they sometimes try really hard to be indistingushable.
I recently got a mail from an insurance company that they were upgrading the login method (red flag). The domain in the link contained wasn't the main domain but a separate customer service domain (red flag 2).
And the main login didn't work as expected before clicking the link in the mail (at least that redirected to the main domain).
Sort of off-topic -- but related to "they would never request that" -- recently, I reached out to Hover's support due to a billing issue. The support agent eventually asked me for my 2FA code and I literally sat back in my chair and mumbled "...what?" I told them, "absolutely not." Then I told them that typically, they would request access and then I would have to approve it. They then proceeded to follow protocol. This agent was literally asking to take over my account, and I guess they can bypass passwords but not 2FA. I know Hover != $Bank, but regardless, it made me very uncomfortable and has me second guessing Hover's security practices.
Banking systems in Baltic countries use a unified 2FA system called SmartID[0]. When authenticating to bank via phone, they ask for two things: your user ID (which is not secret), and to authenticate using Smart ID, which means entering a PIN on your phone.
However, each PIN entry is accompanied by "code check": bank's support person says their 4 digit code, and you can verify that it matches on request for PIN screen. This neatly prevents someone pretending to be a bank during a call, because each PIN request uses a different "code check".
It can still be man-in-the-middle'd. Theres no way to know the attacker isn't calling you on one line while calling your bank on the other. As soon as you've authenticated, they'll continue talking to your bank, and fob you off with some excuse like "oh, the system is down, can you call back tomorrow".
Attacker wants Victim's code. Attacker calls the Bank impersonating Victim, and also calls Victim impersonating the Bank. Bank tells Attacker the code check, Attacker tells Victim the code check, Victim sees the match and enters their PIN into the Smart-ID app, and Attacker's phone session with Bank is now fully authenticated and has no more need for Victim.
I never thought about this, but yes, I think it can be MITM'ed exactly as you described. Same attack can probably be performed on the web, where Smart ID is also a sign in method.
I like how the ones in my country work, when you want to send money you have to sign the transfer with the 2fa app, and the 2fa app itself will display how much money you are transferring, preventing an mitm from displaying one amount but actually sending another. However the recipient is not displayed. So a mitm could modify a legitimate transfer to have another recipient, stealing the $100 destined for your utility bill. But at least that is not a catastrophic loss.
In the linked article on the words "the scammers can get around that, too" [1], there's an account that claims the legit bank did in the past ask for the 2FA on a phone call, in pretty much exactly the same way the scammers did.
> Mitch said his financial institution has in the past verified his identity over the phone by sending him a one-time code to the cell phone number on file for his account, and then asking him to read back that code.
The advice from Krebs about phone calls is never talk to "the bank" (etc) when they call you, always you have to call them back. But the bank _will_ really sometimes contact you "out of the blue" to ask you about potential fraud on your account. You just have to hang up and call them back, you can't tell the difference based on "reasons".
It is very hard for the end-user to tell what 2FA request is "for no reason". I think we need to focus not on what the "reason" is or if it's "out of the blue", but, the equivalent of "call them back" for online too -- don't click on a link in an email, etc.
No matter what, it's not easy, especially for less technical users. The linked account is a security professional that fell for it -- I personally don't have the hubris to think I never would.
There have been times when an actual bank asks me to do something I know is insecure, and I consider resisting it, but I just didn't have the energy for it, I figured it really was the real bank just being idiotic and I wanted to get on with my day (and guess what, it was, I was right).
While "call them back" is good practice, you should remember that even outgoing telephone calls aren't authenticated or encrypted. An advanced enough attacker can totally redirect your outbound calls too - it's just a little harder without an insider in your phone network.
What, and trust that they didn't compromise the hardware manufacturing supply chain? Not today, criminals! I design and construct my own one time burner phone from silicon I personally extracted and refined, it's the only way to be secure!
But don’t just google the location! The scammers are onto this now and have set up fake call centres and banking branches to trick you.
You need to start from a reasonable root of trust like your local government. Go down to city hall and ask them to pull the business license for the organization, and visit the address on file there and work your way down through the organization to the department you’re trying to contact.
The attacker rings your phone company up, impersonates you, and gets your phone line added to a company plan where all dialled phone numbers are first passed to a company phone system to allow the mobile phone to act like an internal phone - so for example you can dial "753" to ring the phone in room 753 of your company office. Calls will only go to the external phone network if the internal company one rejects them.
Then the attacker can intercept any outgoing call.
Feasible. Far more work required, and the plan switch should trigger all sorts of red flags (and thus verifications) before you even place a single phone call.
Perhaps orders of magnitude more likely than someone getting root on your telecom network is someone simply convincing you that an attacker's VOIP number is the official support number you wanted to call.
That's not the same thing! Here the scammer's app is saying "enter the one-time token generated by your device", then passing that on to the phisher. Your quote is about letting the bank know that the device is in the possesion of the person they are talking to.
> OTP Agency customers would enter a target’s phone number and name, and then the service would initiate an automated phone call that alerts that person about unauthorized activity on their account. The call would prompt the target to enter an OTP token generated by their phone’s mobile app (“for authentication purposes”)
What are you saying is the distinction that an ordinary user should be expected to distinguish, between a phone call that says it's from your bank alerting you to fraud and asking you to read back a 2FA code, and... a different kind of phone call that says it's from your bank alerting you to fraud and asking you to enter an OTP code in a different way?
It's a pretty similar thing. In these particular cases, you and I could realize that a bot asking you to use keypad to enter the code is more suspicious than a human asking you to read it. But it's not like humans can't scam you too, as in the other story I linked to from krebs. And it's all a bit subtle and overwhelming for the average user (who of course encounter bot voice systems all the time when dealing with 'legitimate' businesses these days).
The critical aspect about this is, "What can I do about it?"
For most hacks, the answer is, more or less, "Nothing." For a social engineering hack like this, you can be aware and avoid falling victim to this.
For me, reading this article, that's the meat of it -- I am trying to figure out how vulnerable I specifically am to this, and what I need to do to stay safe (and what I need to recommend to my family and friends). Sometimes it's "hope the organizations that have your data are secure", but this time it's the same advice I usually give, "Don't ever tell anyone anything, and NEVER give out passwords to anyone."
> but this time it's the same advice I usually give, "Don't ever tell anyone anything, and NEVER give out passwords to anyone."
OK, but if the legit banks are actually *asking you to read back 2FA codes on the phone"... I assume you include a 2FA code as a "password" since that's what we're talking about... you'd just refuse to talk to them when they call you about potential fraud? Find a new bank that doesn't do that?
Krebs advice to "never give out personal info or 2FA codes when they call you, always call them back at the number on your card" seems like a more useful/actionable appraoch to me than your "never give them personal info or 2FA codes at all".
So, anyway, yeah, krebs advice is "actionable", but... it's not easy. To remember, or to do when you're busy and trying to get on with your day dealing with banks and other bureacracies that routinely "legitimately" ask you to do crazy things.
> OK, but if the legit banks are actually asking you to read back 2FA codes on the phone"... I assume you include a 2FA code as a "password" since that's what we're talking about... you'd just refuse to talk to them when they call you about potential fraud? Find a new bank that doesn't do that?
You find independent corroboration of what they're telling you. If the only evidence you can find in your account that something went wrong is what someone is telling you over the phone, it's almost certainly itself an attempt at fraud.
If you can't, reveal nothing and reach out to them separately (call the bank back) to find out more.
I think I'm going to go with krebs advice which is just call the bank back right away as first step, not as something you do after you on your own try to "find independent corroboration." Just hang up call them back at the number on the back of your card. Only provide personal info when you've called the known number, not when you've received a call, period. (which is actually different advice than "never provide personal information at all", or "only provide personal information after doing your own independent investigation for corroboration")
Okay, that sounds great. I'm going to continue to do things that include but aren't limited to using a phone and human speech to better understand the situation.
I guess we'll find out only if/when someone tries to use one of those sophisticated phish's on us!
Note in the linked krebs story the person thought they were doing that "corroboration"....
> But Mitch knew enough of scams to understand that fraudsters can and often do spoof phone numbers. So while still on the phone with the caller, he quickly logged into his account and saw that there were indeed multiple unauthorized transactions going back several weeks.
He "independently corroborated", they were calling him about fraud, and there WAS fraud! The whole thing is the story of a guy who is actually a security professional and thought he was being smart, and got tricked, and is now really embaressed.
I am sure you will reply that you are smarter than him and will never be tricked, you will do the correct corroboration, not corroborate the wrong thing. Everyone who ever gets tricked also thinks that, but you are probably more correct than they.
But that's why I think it's better to make the "rules" as simple as possible, not be like, oh, sure, I'm going to embark on some spur-of-the-moment "independent corroboration" investigations... you start playing games, they're probably better at the games than you. (I mean, not you, I know you are better than anyone else, but the other people who may be reading this and may be mere mortals, like me). And still you (I mean "one", not you of course, I'm speaking of typical people) might get tricked, because the system is not set up in such a way that it's easy to avoid universally.
It's always the same.
Don't click a link, type it yourself, of course your banks address and not the link from the mail.
Don't answer a phone call, call them back.
> The advice from Krebs about phone calls is never talk to "the bank" (etc) when they call you, always you have to call them back. But the bank _will_ really sometimes contact you "out of the blue" to ask you about potential fraud on your account. You just have to hang up and call them back, you can't tell the difference based on "reasons".
Don't forget that you have to call them back by looking up your bank's phone number yourself from a trusted source (perhaps their HTTPS website). Obviously just calling back the number they called you from (or provided to you) is useless.
My cards all have a toll-free number on the back of the card. When I get a call, text, or email from my CC company that requires a phone call, I call them at that number.
You're really saying "most" banks don't have a customer service number on the back of their payment card? Sorry, no, this just isn't true.
I just checked my own debit and credit cards. 27 (twenty-seven) of them have a phone number printed on the card itself, only one doesn't - that's SoFi Money debit card, it says "for assistance please visit the SoFi app or SoFi.com." it's also just one extra step to phone support - I opened the app and clicked "help" and there was "Call Money support" as the first option.
This hasn't happened to me personally, but I've read of security-conscious people receiving legitimate fraud-warning calls from their bank, and then struggling to get back in contact with the right people. Not every bank is set up to deal with security-conscious customers, apparently.
I've dealt with several companies and banks (mortgages) that were very weirded out by me saying "I'll call you back to verify you are the bank"... Even up to their security people.
"Hi, we need to authenticate a recent transaction of $high_value_item, well send you a verification code to prove we are $company_x."
<receipt of OTP code via SMS from $company_x>
"Can you repeat the verification code to authenticate?"
"Of course this isn't a scam, we must be $company_x, how else could I send you the verification code?"
I can definitely see general members of the public falling for this sort of scam - because they are being led to believe it's not a one-time-password that they're relaying at all, and some organisations do use verification codes of that sort, although usually it's to verify ownership of a particular mobile telephone number when setting up an account or pairing an app or similar.
I wouldn't expect non-technically savvy folk to immediately spot the difference between a verification code and a one-time-password.
It might be good if the OTP SMS message had text along the lines of "Do not give this code to anyone under any circumstances, regardless of who they claim to be employed by." - not that I would expect it to help in all cases.
(tbh - I was actually quite impressed, the English skills of the person on the other end of the telephone were significantly better than the average tech support call center person).
Instead of asking me for my 2FA code If the bank told me what the code was and I confirmed it on my device then would I be able to trust them? Is there any reason 2FA can’t be used in “reverse” like that?
When you call Amex for a while (and maybe still) will send a onetime password for things that need added verification and ask you to share it with them. The text itself says don’t ever share it.
Some banks will request a 2FA code. I had Citi call me, then send me a code via SMS, then ask for the code on the phone. The SMS looked identical to the one I would get when logging in. My spider sense started tingling and I declined and hung up. Called them back directly and sure enough it was really them.
Unfortunately, both Microsoft and Apple have conditioned users to just provide their credentials out of the blue when asked. Microsoft in office, which just randomly asks me for my credentials to perform some communication between app components (I see this a lot when opening powerpoints for some reason), and Apple because my iOS devices are constantly wanting me to re-auth with my appleid. So people probably don’t think twice about it. I know my kids think constantly canceling an appleid login prompt without reading it is just part of using an iPad.
> I disagree. TOTP-based 2FA is leaps-and-bounds more secure than SMS based 2FA and will stop nearly all attempts to access your account.
At present, you are right. In the future, this may not be true, especially the "will stop nearly all attempts" part of what you are saying because the weakness in any security strategy is people.
Hardware tokens were commoditised by yubikey but they really should be TPM based, until there’s critical mass it’ll be a nuanced technology and Yubikey clearly don’t have the clout.
Both Windows and Mac support host-based FIDO keys. Of course, the downside here is that you...can't move them to a new computer. So they're sort of hard to use on their own, hence people still turn to portable (but less secure) solutions like TOTP and SMS.
Fair point, I’m not super familiar with hello. The problem of cross-computer access is solvable* - add cryptographic trusts to transport encrypted data across insecure hardware.
*I didn’t say it’d be great user experience though.
Yep, Apple solves this by moving FIDO key material around via iCloud, I believe. But it requires a good syncing mechanism like that.
In principle it's similar to the password manager problem, which is a bit ironic: if everyone used password managers, most of the same security issues would be resolved. (There are a few cases where a FIDO key is better than a password manager, but not many!)
So your timing is off, but otherwise yes, TPM effectively can do what a yubikey can do, but it can also do more than that, especially in the TPM2 version.
An increasing number of websites are now offering their own authentication app, which uses a secure back channel to push authentication requests down to the user’s device.
While it’s a pain to have a dozen authentication apps on your phone, IMHO this method is just as secure as a hardware module while being much more convenient.
I’m sure that there is a start up that recently announced itself here on hacker news that is creating a universal authentication app that will allow any website to authenticate users in this way. Great idea.
How does that help? If I put my credentials into a phishing site and then get a prompt on my phone to approve a login, why wouldn’t I click approve? Plus, then the attacker often gets a cookie showing their device passed 2FA.
The newest authenticators make a fingerprint of your browser and use that to select a random number that they show you in the app, along with other "controls". You have to pick the correct number, which of course the attacker will not have.
The best practice is a piece of paper with backup codes on it. And if you don't store that properly, you're out of luck. Nothing is perfect, but paper in a safe is pretty good. The cryptocurrency world has introduced titanium backup code holders, where the code letters are literally etched into titanium. Bullet proof, fire proof, etc..
It'd be nice, but support for them around the web seems to be mostly terrible. Only a tiny handful of sites support it at all, and most of the ones that do support it don't support more than one, which seems kind of essential to actually use it long-term and guard against the tokens breaking or getting lost or damaged.
I had been thinking of Github and Cloudflare, but I actually just checked both of them and they do now allow multiple keys to be registered. So I guess that's gradually getting better.
It's still pretty amazing that AWS still doesn't allow multiple 2FA methods though.
Two factor with a code device (totp, rsa token, sms, etc) isn't effective for phishing, but it is effective against non-interactive attacks like cracking password files or brute force or password reuse.
Something like webauthn that ties the token to the usage context and so addresses phishing (until the host security is broken) and also addresses non-interactive attacks is clearly better from that perspective, but it's not as easy to setup two of those as it is to setup TOTP on two devices at the same time or be able to put your SIM in another phone or get a new SIM (this is, or course, a negative if someone else gets a new SIM for your number). And then there's the extra cost (until/unless it's more integrated into devices people already have)
It doesn't work so well if the phishers also make a 2fa phishing page. People confused enough to put in their password on the login page will also put it on the 2fa entry phishing page.
I work in the industry if it wasn't obvious though for years now nothing to do with phishing but I do have some experience shall we say.
1. Building a phishing page and can accept 2FA and in real time(remember code is useless after 30 sec) logs in to an account is much harder. most attacks are low quality junk.
2. From a detection standpoint, this is awesome. the attacker has to log in real-time. he will likely send that link to hundreds of people = good telemetry to detect anomalies\fraudulent logins.
3.* Another pain I remember observing was regarding the login process itself. Websites tend to change their log in UI\processes, different websites have different layouts.
This makes it frustrating and tedious maintain, bank changes the login prompt, attacker has to modify code to accommodate that.
4. Data doesn't lie, it is not bulletproof but it does offer significantly higher level of protection. saw that in actual enterprise with my own eyes.
Sure, it raises the bar, maybe I should have said it's not entirely effective, rather than it'd not effective. Long story short, if you want your corporate logins to not get phished, 2fa with codes (or push to accept in an app) isn't sufficient, although it may reduce the rate.
It does nearly eliminate other classes of attack (depending on details: if you're using six digit codes, 1 in 1M isn't zero; if you're using app to accept/deny, some users will say yes when it wasn't actually them)
so you're suggesting that someone is going to attempt to guess a 6 digit code?
this is not offline brute-force, you're not going to iterate over thousands of codes...
Passwords are permanent, that's the main difference. the code is only relevant to 30 secs after that it is useless. passwords are always useful because they never change.
Also people tend to re-use or slightly modify their password. with TOTP codes, the previous code doesn't tell you anything regarding the next code.
> so you're suggesting that someone is going to attempt to guess a 6 digit code?
Yeah, what else are you going to do when you get a 2fa prompt that you're not prepared to phish? It's unlikely to be right, and you only get a couple tries, but just because it's unlikely to be right doesn't mean it won't be sometimes. And you probably already blew your cover getting to the prompt, may as well make a go.
Correct me if I'm wrong, but won't WebAuthn with hardware tokens still be vulnerable to MITM phishing attacks? Ones where the attacker sets up a convincingly fake website and forwards the signature to the actual server?
The signature will be for the convincing fake and won't be valid for the real site. Plus, your hardware key won't even recognize the fake site as an enrolled site, and won't even generate a signature for the fake site!
I think that's mostly right anyways. There's a very helpful explanation somewhere upthread and that's what I understood from it.
> This service (and all others mentioned in this story) assumes the customer already has the target’s login credentials through some means.
> OTP Agency customers would enter a target’s phone number and name, and then the service would initiate an automated phone call that alerts that person about unauthorized activity on their account. The call would prompt the target to enter an OTP token generated by their phone’s mobile app (“for authentication purposes”), and that code would then get relayed back to the bad guy customers’ panel at the OTP Agency website.
There are OTP algorithms that allow both parties to identify each other (not just one way where the server confirms the identity of the client), so you can't be subject to a MITM attack.
In EU, 2FA is mandatory, but it's really frustrating that the law allows to use SMS codes as a second factor. The typical hack in my country is to use a rogue employee in a phone shop to clone a SIM card, and then you are screwed up.
Push notifications to a smartphone app for login approvals is by far the most convenient 2FA method and also more secure than TOTP or SMS. I use it wherever I can.
Push notifications mean that if you believe you're logging in, and the crook is actually logging in, (not a coincidence, they understand how this works) you get a push notify, which you accept because you think you're logging in, and you thereby let the crook in. Brilliant.
With Okta, it tells you the approximate location of where the login request is coming from. So unless the crook happens to be in the same city as me, I'm going to immediately see that something is wrong and decline the request.
Not perfect, sure. Webauthn is definitely more secure, but far less convenient.
Why isn't it about making it functionally impossible? You can break WebAuthn if you can guess a 128-bit AES key. You won't, but it's not impossible it's just astronomically unlikely if everybody spends their lifetime trying.
That's why Google gave all its employees Security Keys. Instead of "Well, we spend a little bit of money on some half-solution but we just raised the bar and so we'll have to spend more forever and always risk phishing attacks" they just solved the problem.
This saves you extra money because your adversaries stop trying. Not only are remaining attacks unsuccessful, they become much rarer and the associated clean-up (even if it's just helpdesk reassuring employees that although they fell for that scam email claiming to be from HR their credentials are fine) cost is reduced.
Think about SSH. People scan and attack every SSH server on the public IPv4 Internet. But not on IPv6. Why not? Because it's statistically useless to attempt with 128-bit addresses. You're just wasting your time and money.
Remote attacks are not the only attacks and nothing can make it impossible as long as people are involved. Security keys are easy to steal and people are easy to trick or coerce.
Doesn't webauthn have the same issue? If you think your logging in, but you're actually on a phishing site you'll have given the attacker a response they can forward onto the real webserver?
No. In WebAuthn site A can only request credentials for site A there is no way to say "Oh, er, I'm totally site B, give me the site B credentials". Everything is cryptographically tied to the exact DNS name of the site.
So the attacker at best gets valid credentials for their phishing site, which in WebAuthn are deliberately uncorrelated to other credentials, the attacker can't do anything useful with that information. In practice, of course you don't have or want credentials for their phishing site so they just get a Javascript error and give up.
Just run through the scenario you have in mind: would the attacker not be able to easily automate the forwarding of the OTP? Would grandmas still be able to use online banking? It's a trade-off, and validity periods so short that the user has to race a potential attacker, I don't think that's viable.
They only last for 30 seconds, requiring better infrastructure(automated logins) which also tremendously helps with detection.
The vast majority of phishing is just storing passwords for later attempts.
TOTP by design can be stronger than password. the seed can be pseudo-randomly generated therefore you cannot guess the code without it, even if you have previously generated codes.
I get a lot of eye rolling when I go around pointing out that one-time codes are not, by definition, multi-factor auth. Google and some other services properly refer to this auth method as "two-step verification."
Something you know. Something you have. Something you are. Known passwords of any type are all in the first category, and they will always be highly phishable, and using more than one of the same factor will never be "multi-factor."
I'd still call it something you have. If someone kidnapped you, you wouldn't be able to reveal your TOTP password without your device.
The problem is the communication channel isn't bound to the authentication context the way it would be with a fido key. But that could be a flaw with any type of authenticator (albeit its much easier to seamlessly fix with other types) - its not about what type of factor it is.
It is something you have, until it is automatically downgraded to something you know. I could create all manner of elaborate schemes that involve tokens and biometrics and geolocation, but if that scheme simply produces a one-time code for you to put in your brain and produce at will, I'm still using a knowledge factor at the point of authentication.
I've always had trouble conceptually with two factor authentication conceived of in this way. If a phone is something you have, then it gives you a code, and you put in that code, so it's really just a code.
If it's something you have, well, probably a key right? A usb key? But it's a code on the USB key.
If it's something about you (voice, fingerprint, etc), or a location, it's ultimately something represented as information.
That's not to say it's a bad philosophy or less secure. It's better, not worse. But it seems to be conceived of and framed in a way as though it's appealing to something other than stuff that gets turned into computer-accessible information.
The one "hard" category that seems to make sense to me has to do with hard-wired networks, and having to be in a physical place to access a system that is not online. That creates a real distinction that doesn't boil down to some form of computer-comprehensible information.
But you yourself don't know the code on the hardware token, nor do you yourself know the information gathering, encoding or decoding for biometric information. Those are still pieces of information, but they aren't "something you know."
To your later point, some later versions of these original authentication factors have added "somewhere you are" to the list.
Right, the new factor is working fine, but instead of providing authentication, it's being used to merely attest to the validity of an additionally provided randomized knowledge factor, which is what gets actually for used for authentication.
Isn't the same way the used to get entry from a TAN list?
Pose as a valid receiver, ask for authentication, pass it through to access whatever you want.
Don't give an answer if you didn't initiate the process.
There's an interesting way you can implement TOTP that avoids the phishing problem described in the article. The method doesn't work for all situations, but it works for many -- it works particularly well if all you're trying to do is protect access to a mobile app.
At my company we have a mobile app and we use TOTP for MFA. But instead of requiring a separate app like Google Authenticator to generate and type in 6 digit codes, we store the TOTP secret and generate the 6 digit codes all internally. In other words, we bundle the functionality of Google Authenticator directly into our own app.
From the user's perspective, it's wonderfully simple: the user scans a QR code on our website and they're instantly enrolled in MFA. Then for all subsequent logins, they just type in their username and password -- the 6 digit TOTP code generation is handled silently in the background.
With this approach you get all the benefits of TOTP-based MFA, but without the phishing risk. For all the mobile apps out there that offer TOTP as a form of MFA, I'm surprised how many of them require you to use a separate authenticator app.
Really fascinating idea I hadn’t heard of before. Felt “icky” at first pass, but it’s no different to having a separate TOTP gen app, in fact given it stops you from having to copy/paste the code around, possibly less exposure there.
The only downsides I can think of is that if the app local data is exposed, you possibly lose your cached creds and the TOTP seed.. but most apps are toast if there’s a full local data exposure. I guess the other challenge is if you have to do a (full) app reinstall, you’ve got to re do the MFA config. But app reinstalls seem extremely rare these days (basically only when you get a new phone)
> I guess the other challenge is if you have to do a (full) app reinstall
Yeah, that's true, if the user does a full app removal and re-install then they would need to re-enroll in MFA. But for app updates they'd be ok.
> The only downsides I can think of is that if the app local data is exposed, you possibly lose your cached creds and the TOTP seed..
That's a good point too, but what you're describing would probably require someone to fully compromise (root) a phone. If that happened, you'd be SOL on many fronts. At my company we try to safeguard against rooted phones by 1. only holding user credentials in memory and 2. pairing our app with a public key that encrypts the password as soon as it's entered (our servers then decrypt it with the private key upon receipt).
It'd be the same process that you have to follow if you lost your phone and, along with it, all the TOTP seeds that were stored in your Google Authenticator. You'd have to go through whatever process the company requires to confirm your identity through alternative means and allow a re-enrollment in MFA.
I suppose that could work, but one potential advantage of TOTP is that the secret/seed used to generate the 6 digit codes is never transmitted and not at risk of being intercepted.
It's also probably more user-friendly to put a TOTP secret/seed on a device than it would be a client certificate. A certificate would probably be too big to easily scan with a QR code. QR codes can hold large amounts of data, but with more data the QR becomes larger and the detail becomes very fine. The camera needs to be very good, lighting needs to be very good, etc.
Neither is the key for a ssl cert generated on the device? In fact, with qr enrollment the 2fa approach does transmit/expose the secret (probably over https, but still).
True, you can't generate a QR code without transmitting the TOTP secret/seed in some fashion, but it's a one-time event that's typically done over HTTPS like you suggested.
Just as with normal server side TLS, the client doesn't send its private key (and it's not known to anyone but the client), so intercepting the certificate doesn't do the attacker any good.
But if communications intercept is possible, even with TOTP the attacker could intercept the TOTP token for that session and use it to log in himself.
They would have to re-enroll in MFA, but that's the same thing that happens today if someone uses Google Authenticator and gets a new phone (or uninstalls Google Authenticator).
That additional information would vary, but you basically would follow the same process for someone who loses their device (and along with it their TOTP authenticator app). You might send them a SMS code, require them to call in, etc.
Basically it'd be no different than what companies already do today when someone loses their device and their authenticator app.
So, it sounds like one could use this to legitimately recover an account where one has lost the phone number, the service provider requires SMS auth to get back in? Using it on yourself and it becomes account recovery as a service.
> an uptick in services on the cybercrime underground that allow attackers to intercept one-time password (OTP) tokens [...] we’ve seen actors provide access to services that call victims, appear as a legitimate call from a specific bank and deceive victims into typing an OTP or other verification code
168 comments
[ 2.9 ms ] story [ 226 ms ] threadUnfortunately he fails to mention that there is a way to do 2fa that does prevent phishing: Hardware tokens with the webauthn protocol.
The fault here lies with victims answering a prompt to enter their 2FA out of the blue. Just as with passwords and other such info, the bank will never request it for no reason.
A hardware token using webauthn protocol is most secure though, yes.
Put differently: if you assume the user to be infallible, there's very little reason to use 2FA of any kind. (Don't believe me? Describe to me a threat which applies to an infallible password-only user which is mitigated by non-FIDO2 second factors.)
It also isn't defeated by 2FA, since they've physically installed something on your machine to detect your keypresses. They just capture your password and the sms code.
- They can install a wifi-enabled* keylogger that exfiltrates your OTP. Yes, they have to use the OTP before you do, but that seems solvable to me--just program the keylogger to transpose one of the six characters that comes after your (now known) password.
- They exploit any number of likely plug-and-play vulnerabilities in common OSes (e.g. https://www.thetechherald.com/tech-news/disable-plug-n-play-...).
- They steal your computer. Are you using FDE? If not, your cookies are sitting there on disk waiting for them.
- They...steal your phone next time you forget it at your desk. ;)
Are there scenarios where TOTP can protect against a non-phishing attack? Yeah, I can construct one if I really have to. (I think you're thinking too locally; my top argument for TOTP would be that I can rarely be sure the identity provider has implemented reasonable quotas against password brute-forcing--and who knows how well they secure things like server logs against rogue insiders?)
But if you tell me you use TOTP because you're afraid of a local attacker plugging in a keylogger--and not because of phishing--I think your priorities are out of whack. :)
* Or they use a covert channel, but I'm not serious about this part: https://dl.acm.org/doi/10.5555/1267336.1267341
deployment of a keylogger means your host is compromised, from there you can do so much you really don't need someone's password...
2FA is for plain phishing attacks. building phishing attacks against 2FA is significantly harder and usually easier to detect\protect from.
Now, granny may not be down with the latest Tik Tok trends, but she has seen keys before, and the analogy is strong - so I think she can get this right.
To be fair, scammers have been successful with scams that involve an actual bike courier (presumably the scammer or a friend) coming to pick up your bank card, but that at least feels a bit reasonable because it does say the card remains property of the bank, so, sure, have your card back. And I'm also guessing this is a much higher friction scam than the average "Phone support in India" setup. I reckon scam dozens of people for their card this way and somewhere around the 100 victims mark the guy opening the door to your courier has a baseball bat, or worse, and your courier has a bad day.
If one is using a dozen services that auth with 2Fa and needs to log in once per day, that's a lot of windows of opportunity. Multiply that by 86,400 numbers phished that day.
Phishing is enormously more common than sim-swapping because, as described in TFA, it can be fully automated. Going from SMS to TOTP fixes a rare attack but does not fix a common attack.
In one of the linked articles the scammers pretended to send a one-time token and asked the victim to read it back. This is the same process my top-10 US-based bank uses, so it wouldn’t necessarily raise any red flags.
For example a phishing site could trick me into authenticating into a fake site, and give them a session at the real site as a result. They won't have my actual credentials but they could have a session which is enough to do a lot of damage.
I don't think Webauthn guarantees that the site I'm authenticating to is the site I'm supposed to (though I may be wrong here, I didn't read into it too deeply). As far as I know it still relies on TLS for that, and regular phishing and typosquatting show that this is not airtight. It would be great if the authentication worked both ways, the server would authenticate to the client as well as it does to the server.
It does raise a few other questions too. If every site uses Webauthn, I will have to update every site when I get a new yubikey. That's going to be a PITA.
A solution for that would be using an identity service.. Like "Sign in with Google". But I would never trust a commercial service like Google, Facebook, Microsoft for this. It would have to be something open and privacy-safe.
The fake site needs to be hosted somewhere, presumably not on the same origin as the real site. As such, your key will be unable to sign a message for the phishing site regardless of how hard you try.
This is the core difference with SMS/TOTP. With those models nothing stops you from handing the material over to a site on a different origin and letting them reflect that material to the target site. With webauthn, the thing you hand the phishing site is useless for authenticating on the target site.
WebAuthn needs the DNS name of the site to exactly match. This isn't for humans, who think 1 and I are pretty similar, it's for a machine, which thinks they're different. Phishing and typosquatting don't get you google.example they get your google.comsecurityupdatelogin.example or goggle.example which do not match. Now, in principle you could attack the Ten Blessed Methods to get yourself a real, legitimate (albeit fraudulently obtained) certificate for the exact DNS name of a real popular site, but that's not easy, and indeed making it more difficult is a continuing focus of Web PKI work. Also, defenders can make it arbitrarily harder if they put work in.
I never tired of explaining the clever trick that makes this possible, so here goes (for the easy case of a cheap Security Key, something like an iPhone can do fancier tricks with more complicated explanations)
When you enroll at some.example, your Security Key is told we're enrolling at SHA256("some.example"). A button flashes and you push it. The Security Key picks a completely random public/private key pair. It uses the private key to sign a document, "Hello, I am this Security Key, I checked a human was present" and it encrypts the private key with its own symmetric key and with that SHA256("some.example") parameter as "Extra data" in an AEAD (Authenticated Encryption, Extra Data) cipher to produce a large opaque blob it will claim is a "random identifier". It sends the public key, the "random identifier" and the signed message back to your web browser. You are enrolled.
When you come back to the site, the site says oh, your account requires a Security Key, prove you still have it. It sends one or more of those "random identifiers" corresponding to enrolled Security Keys. Your browser talks to any Security Keys plugged in, hey, I'm at SHA256("some.example") and it asked if anybody can prove I'm still some-huge-identifier ?
Your Security Key tries to decrypt some-huge-identifier using its symmetric key, and the Extra Data SHA256("some.example"). Maybe it gets a success and a private key. The little button flashes and you push it. In this case it can sign a message using the private key, "Yes, I'm still me, I checked a human was present"
But, if anything goes wrong, that decryption will fail. If this is some-other.example, SHA256("some-other.example") won't match and decryption fails. If the site picks random gibberish instead of your identifier, decryption fails. If you plugged in the wrong Security Key, decryption fails.
You are unable to even try to authenticate to the wrong site. And if they enroll you which they can do, now they've got useless credentials for you to sign into their site that are unrelated to the credentials on other sites. They're even deliberately not correlated and they aren't even wasting space on your Security Key, the Security Key (this is why the trick was so clever) doesn't store anything to make all this work! All the storage is in the Relying Parties, and it's all storage of public data that's harmless when inevitably crooks steal it.
I really appreciate the breakdown of how it works! I agree this makes phishing almost impossible (at least without obtaining a valid cert which is in itself really hard for a non state actor)
I recently got a mail from an insurance company that they were upgrading the login method (red flag). The domain in the link contained wasn't the main domain but a separate customer service domain (red flag 2).
And the main login didn't work as expected before clicking the link in the mail (at least that redirected to the main domain).
It really can't get much worse.
However, each PIN entry is accompanied by "code check": bank's support person says their 4 digit code, and you can verify that it matches on request for PIN screen. This neatly prevents someone pretending to be a bank during a call, because each PIN request uses a different "code check".
[0]: https://www.smart-id.com
Attacker wants Victim's code. Attacker calls the Bank impersonating Victim, and also calls Victim impersonating the Bank. Bank tells Attacker the code check, Attacker tells Victim the code check, Victim sees the match and enters their PIN into the Smart-ID app, and Attacker's phone session with Bank is now fully authenticated and has no more need for Victim.
WebAuthn is really what is good enough. Luckily it's well supported on all important platforms so there's really no excuse using anything worse.
> Mitch said his financial institution has in the past verified his identity over the phone by sending him a one-time code to the cell phone number on file for his account, and then asking him to read back that code.
The advice from Krebs about phone calls is never talk to "the bank" (etc) when they call you, always you have to call them back. But the bank _will_ really sometimes contact you "out of the blue" to ask you about potential fraud on your account. You just have to hang up and call them back, you can't tell the difference based on "reasons".
It is very hard for the end-user to tell what 2FA request is "for no reason". I think we need to focus not on what the "reason" is or if it's "out of the blue", but, the equivalent of "call them back" for online too -- don't click on a link in an email, etc.
No matter what, it's not easy, especially for less technical users. The linked account is a security professional that fell for it -- I personally don't have the hubris to think I never would.
There have been times when an actual bank asks me to do something I know is insecure, and I consider resisting it, but I just didn't have the energy for it, I figured it really was the real bank just being idiotic and I wanted to get on with my day (and guess what, it was, I was right).
[1]: https://krebsonsecurity.com/2020/04/when-in-doubt-hang-up-lo...
You need to start from a reasonable root of trust like your local government. Go down to city hall and ask them to pull the business license for the organization, and visit the address on file there and work your way down through the organization to the department you’re trying to contact.
How?
Then the attacker can intercept any outgoing call.
> OTP Agency customers would enter a target’s phone number and name, and then the service would initiate an automated phone call that alerts that person about unauthorized activity on their account. The call would prompt the target to enter an OTP token generated by their phone’s mobile app (“for authentication purposes”)
What are you saying is the distinction that an ordinary user should be expected to distinguish, between a phone call that says it's from your bank alerting you to fraud and asking you to read back a 2FA code, and... a different kind of phone call that says it's from your bank alerting you to fraud and asking you to enter an OTP code in a different way?
It's a pretty similar thing. In these particular cases, you and I could realize that a bot asking you to use keypad to enter the code is more suspicious than a human asking you to read it. But it's not like humans can't scam you too, as in the other story I linked to from krebs. And it's all a bit subtle and overwhelming for the average user (who of course encounter bot voice systems all the time when dealing with 'legitimate' businesses these days).
For most hacks, the answer is, more or less, "Nothing." For a social engineering hack like this, you can be aware and avoid falling victim to this.
For me, reading this article, that's the meat of it -- I am trying to figure out how vulnerable I specifically am to this, and what I need to do to stay safe (and what I need to recommend to my family and friends). Sometimes it's "hope the organizations that have your data are secure", but this time it's the same advice I usually give, "Don't ever tell anyone anything, and NEVER give out passwords to anyone."
OK, but if the legit banks are actually *asking you to read back 2FA codes on the phone"... I assume you include a 2FA code as a "password" since that's what we're talking about... you'd just refuse to talk to them when they call you about potential fraud? Find a new bank that doesn't do that?
Krebs advice to "never give out personal info or 2FA codes when they call you, always call them back at the number on your card" seems like a more useful/actionable appraoch to me than your "never give them personal info or 2FA codes at all".
So, anyway, yeah, krebs advice is "actionable", but... it's not easy. To remember, or to do when you're busy and trying to get on with your day dealing with banks and other bureacracies that routinely "legitimately" ask you to do crazy things.
You find independent corroboration of what they're telling you. If the only evidence you can find in your account that something went wrong is what someone is telling you over the phone, it's almost certainly itself an attempt at fraud.
If you can't, reveal nothing and reach out to them separately (call the bank back) to find out more.
I think we'll both be in pretty good shape!
Note in the linked krebs story the person thought they were doing that "corroboration"....
> But Mitch knew enough of scams to understand that fraudsters can and often do spoof phone numbers. So while still on the phone with the caller, he quickly logged into his account and saw that there were indeed multiple unauthorized transactions going back several weeks.
https://krebsonsecurity.com/2020/04/when-in-doubt-hang-up-lo...
He "independently corroborated", they were calling him about fraud, and there WAS fraud! The whole thing is the story of a guy who is actually a security professional and thought he was being smart, and got tricked, and is now really embaressed.
I am sure you will reply that you are smarter than him and will never be tricked, you will do the correct corroboration, not corroborate the wrong thing. Everyone who ever gets tricked also thinks that, but you are probably more correct than they.
But that's why I think it's better to make the "rules" as simple as possible, not be like, oh, sure, I'm going to embark on some spur-of-the-moment "independent corroboration" investigations... you start playing games, they're probably better at the games than you. (I mean, not you, I know you are better than anyone else, but the other people who may be reading this and may be mere mortals, like me). And still you (I mean "one", not you of course, I'm speaking of typical people) might get tricked, because the system is not set up in such a way that it's easy to avoid universally.
Don't forget that you have to call them back by looking up your bank's phone number yourself from a trusted source (perhaps their HTTPS website). Obviously just calling back the number they called you from (or provided to you) is useless.
It should say "Call us back at the number on the back of your card", or some such.
I'm sure they're afraid that a lot of users won't figure that out, but it still seems like a weird tradeoff.
I just checked my own debit and credit cards. 27 (twenty-seven) of them have a phone number printed on the card itself, only one doesn't - that's SoFi Money debit card, it says "for assistance please visit the SoFi app or SoFi.com." it's also just one extra step to phone support - I opened the app and clicked "help" and there was "Call Money support" as the first option.
The script went something along the lines of:
"Hi, we need to authenticate a recent transaction of $high_value_item, well send you a verification code to prove we are $company_x." <receipt of OTP code via SMS from $company_x> "Can you repeat the verification code to authenticate?" "Of course this isn't a scam, we must be $company_x, how else could I send you the verification code?"
I can definitely see general members of the public falling for this sort of scam - because they are being led to believe it's not a one-time-password that they're relaying at all, and some organisations do use verification codes of that sort, although usually it's to verify ownership of a particular mobile telephone number when setting up an account or pairing an app or similar.
I wouldn't expect non-technically savvy folk to immediately spot the difference between a verification code and a one-time-password.
It might be good if the OTP SMS message had text along the lines of "Do not give this code to anyone under any circumstances, regardless of who they claim to be employed by." - not that I would expect it to help in all cases.
(tbh - I was actually quite impressed, the English skills of the person on the other end of the telephone were significantly better than the average tech support call center person).
At present, you are right. In the future, this may not be true, especially the "will stop nearly all attempts" part of what you are saying because the weakness in any security strategy is people.
Both Windows and Mac support host-based FIDO keys. Of course, the downside here is that you...can't move them to a new computer. So they're sort of hard to use on their own, hence people still turn to portable (but less secure) solutions like TOTP and SMS.
*I didn’t say it’d be great user experience though.
In principle it's similar to the password manager problem, which is a bit ironic: if everyone used password managers, most of the same security issues would be resolved. (There are a few cases where a FIDO key is better than a password manager, but not many!)
It's already hard to trust OS and browser. Therefore I'd prefer a physical interaction on a device where the behavior cannot be altered.
TPM(ISO/IEC 11889) started 2009
So your timing is off, but otherwise yes, TPM effectively can do what a yubikey can do, but it can also do more than that, especially in the TPM2 version.
Most modern phones have SE(Secure Element) or virtualized secure zone(ARM Trustzone) which can act as de-facto key.
Google already uses it to great success(most people are clueless to that though)
While it’s a pain to have a dozen authentication apps on your phone, IMHO this method is just as secure as a hardware module while being much more convenient.
I’m sure that there is a start up that recently announced itself here on hacker news that is creating a universal authentication app that will allow any website to authenticate users in this way. Great idea.
It'd be nice, but support for them around the web seems to be mostly terrible. Only a tiny handful of sites support it at all, and most of the ones that do support it don't support more than one, which seems kind of essential to actually use it long-term and guard against the tokens breaking or getting lost or damaged.
Do you have any examples besides AWS?
I had been thinking of Github and Cloudflare, but I actually just checked both of them and they do now allow multiple keys to be registered. So I guess that's gradually getting better.
It's still pretty amazing that AWS still doesn't allow multiple 2FA methods though.
This could also be done using client side TLS certificates without restricting the application protocol used on top of the TCP connection.
Something like webauthn that ties the token to the usage context and so addresses phishing (until the host security is broken) and also addresses non-interactive attacks is clearly better from that perspective, but it's not as easy to setup two of those as it is to setup TOTP on two devices at the same time or be able to put your SIM in another phone or get a new SIM (this is, or course, a negative if someone else gets a new SIM for your number). And then there's the extra cost (until/unless it's more integrated into devices people already have)
2FA is very useful against phishing:
https://security.googleblog.com/2019/05/new-research-how-eff...
1. Building a phishing page and can accept 2FA and in real time(remember code is useless after 30 sec) logs in to an account is much harder. most attacks are low quality junk.
2. From a detection standpoint, this is awesome. the attacker has to log in real-time. he will likely send that link to hundreds of people = good telemetry to detect anomalies\fraudulent logins.
3.* Another pain I remember observing was regarding the login process itself. Websites tend to change their log in UI\processes, different websites have different layouts.
This makes it frustrating and tedious maintain, bank changes the login prompt, attacker has to modify code to accommodate that.
4. Data doesn't lie, it is not bulletproof but it does offer significantly higher level of protection. saw that in actual enterprise with my own eyes.
It does nearly eliminate other classes of attack (depending on details: if you're using six digit codes, 1 in 1M isn't zero; if you're using app to accept/deny, some users will say yes when it wasn't actually them)
this is not offline brute-force, you're not going to iterate over thousands of codes...
Passwords are permanent, that's the main difference. the code is only relevant to 30 secs after that it is useless. passwords are always useful because they never change.
Also people tend to re-use or slightly modify their password. with TOTP codes, the previous code doesn't tell you anything regarding the next code.
Yeah, what else are you going to do when you get a 2fa prompt that you're not prepared to phish? It's unlikely to be right, and you only get a couple tries, but just because it's unlikely to be right doesn't mean it won't be sometimes. And you probably already blew your cover getting to the prompt, may as well make a go.
I think that's mostly right anyways. There's a very helpful explanation somewhere upthread and that's what I understood from it.
> This service (and all others mentioned in this story) assumes the customer already has the target’s login credentials through some means.
> OTP Agency customers would enter a target’s phone number and name, and then the service would initiate an automated phone call that alerts that person about unauthorized activity on their account. The call would prompt the target to enter an OTP token generated by their phone’s mobile app (“for authentication purposes”), and that code would then get relayed back to the bad guy customers’ panel at the OTP Agency website.
In EU, 2FA is mandatory, but it's really frustrating that the law allows to use SMS codes as a second factor. The typical hack in my country is to use a rogue employee in a phone shop to clone a SIM card, and then you are screwed up.
You could do a "SIM swap" to a traditional SIM in exactly the same way, using phone customer support or retail store IT.
Prefer WebAuthn.
Not perfect, sure. Webauthn is definitely more secure, but far less convenient.
That's why Google gave all its employees Security Keys. Instead of "Well, we spend a little bit of money on some half-solution but we just raised the bar and so we'll have to spend more forever and always risk phishing attacks" they just solved the problem.
This saves you extra money because your adversaries stop trying. Not only are remaining attacks unsuccessful, they become much rarer and the associated clean-up (even if it's just helpdesk reassuring employees that although they fell for that scam email claiming to be from HR their credentials are fine) cost is reduced.
Think about SSH. People scan and attack every SSH server on the public IPv4 Internet. But not on IPv6. Why not? Because it's statistically useless to attempt with 128-bit addresses. You're just wasting your time and money.
So the attacker at best gets valid credentials for their phishing site, which in WebAuthn are deliberately uncorrelated to other credentials, the attacker can't do anything useful with that information. In practice, of course you don't have or want credentials for their phishing site so they just get a Javascript error and give up.
[1] (The Rise) of (One-Time Password Interception Bots)
Lets give them a code to enter...
"On no! Criminals are phishing our customers to get their code."
They only last for 30 seconds, requiring better infrastructure(automated logins) which also tremendously helps with detection.
The vast majority of phishing is just storing passwords for later attempts.
TOTP by design can be stronger than password. the seed can be pseudo-randomly generated therefore you cannot guess the code without it, even if you have previously generated codes.
Something you know. Something you have. Something you are. Known passwords of any type are all in the first category, and they will always be highly phishable, and using more than one of the same factor will never be "multi-factor."
The problem is the communication channel isn't bound to the authentication context the way it would be with a fido key. But that could be a flaw with any type of authenticator (albeit its much easier to seamlessly fix with other types) - its not about what type of factor it is.
If it's something you have, well, probably a key right? A usb key? But it's a code on the USB key.
If it's something about you (voice, fingerprint, etc), or a location, it's ultimately something represented as information.
That's not to say it's a bad philosophy or less secure. It's better, not worse. But it seems to be conceived of and framed in a way as though it's appealing to something other than stuff that gets turned into computer-accessible information.
The one "hard" category that seems to make sense to me has to do with hard-wired networks, and having to be in a physical place to access a system that is not online. That creates a real distinction that doesn't boil down to some form of computer-comprehensible information.
To your later point, some later versions of these original authentication factors have added "somewhere you are" to the list.
The otp is proof that you "possess" the otp secret.
Then again, it's a shared secret - so if the server side is compromised - all bets are off. Here client certificates/public key crypto does better.
Not really. People don't "know" their totp secret or their RSA secret key.
But yes, when these key-style secrets can be transfered - they behave more like "know of" than "in possession of".
The simple mitigation is probably fido2 auth tokens.
Don't give an answer if you didn't initiate the process.
At my company we have a mobile app and we use TOTP for MFA. But instead of requiring a separate app like Google Authenticator to generate and type in 6 digit codes, we store the TOTP secret and generate the 6 digit codes all internally. In other words, we bundle the functionality of Google Authenticator directly into our own app.
From the user's perspective, it's wonderfully simple: the user scans a QR code on our website and they're instantly enrolled in MFA. Then for all subsequent logins, they just type in their username and password -- the 6 digit TOTP code generation is handled silently in the background.
With this approach you get all the benefits of TOTP-based MFA, but without the phishing risk. For all the mobile apps out there that offer TOTP as a form of MFA, I'm surprised how many of them require you to use a separate authenticator app.
The only downsides I can think of is that if the app local data is exposed, you possibly lose your cached creds and the TOTP seed.. but most apps are toast if there’s a full local data exposure. I guess the other challenge is if you have to do a (full) app reinstall, you’ve got to re do the MFA config. But app reinstalls seem extremely rare these days (basically only when you get a new phone)
Very fascinating idea
Yeah, that's true, if the user does a full app removal and re-install then they would need to re-enroll in MFA. But for app updates they'd be ok.
> The only downsides I can think of is that if the app local data is exposed, you possibly lose your cached creds and the TOTP seed..
That's a good point too, but what you're describing would probably require someone to fully compromise (root) a phone. If that happened, you'd be SOL on many fronts. At my company we try to safeguard against rooted phones by 1. only holding user credentials in memory and 2. pairing our app with a public key that encrypts the password as soon as it's entered (our servers then decrypt it with the private key upon receipt).
How would they re-enroll without their MFA token? Surely the whole point is not to let them login without it?
It's also probably more user-friendly to put a TOTP secret/seed on a device than it would be a client certificate. A certificate would probably be too big to easily scan with a QR code. QR codes can hold large amounts of data, but with more data the QR becomes larger and the detail becomes very fine. The camera needs to be very good, lighting needs to be very good, etc.
But if communications intercept is possible, even with TOTP the attacker could intercept the TOTP token for that session and use it to log in himself.
Basically it'd be no different than what companies already do today when someone loses their device and their authenticator app.
So not intercept, just phish.