Live data from Hacker News

Thieves drain 2FA-protected bank accounts by abusing SS7 routing protocol

arstechnica.com

161–170 of 225 posts

Re: Thieves drain 2FA-protected bank accounts by abusing SS7 routing protocol

#161

Earlier quoted context omitted.

It depends. SMS is better than nothing as a second factor, but SMS has a weird way of worming its way into single-factor status. I think people should avoid SMS 2FA, and should be skeptical of the security of companies that offer only SMS and neither of TOTP or U2F.

This frustrates me endlessly about Namecheap. They only allow SMS, and, for something as valuable as my domain name (figuratively the keys to my kingdom), that's unacceptable.

I transfered my domain to route 53 and let them know this was the reason why.

Re: Thieves drain 2FA-protected bank accounts by abusing SS7 routing protocol

#162
post #33

Last July, NIST called out SMS 2FA as insecure https://www.schneier.com/blog/archives/2016/08/nist_is_no_lo... Second comment: SMS should have been removed long time ago considering the SS7 problems. Better to use a secure token. Is the bank taking responsibility and covering the loss for their customers?

> Is the bank taking responsibility and covering the loss for their customers?

I think they should be required to. Although, isn't it possible that the sum of withdrawn amounts could be so large that the bank simply can't cover the loss, thus making it insolvent?

Re: Thieves drain 2FA-protected bank accounts by abusing SS7 routing protocol

#163

The headline makes it sound as if abusing SS7 was all they needed to do but in fact they had to have the other factor as well so it really is not quite as scary as it at first appears. It also seems from the article that the thieves were able to log in to the accounts with just a password and only needed the SMS to sign transactions. It's different here in Norway; the banks require two factor authentication to log in…

> It also seems from the article that the thieves were able to log in to the accounts with just a password and only needed the SMS to sign transactions.

This "feature" was enabled by default for my Danish online bank as well. I've since disabled it.

Re: Thieves drain 2FA-protected bank accounts by abusing SS7 routing protocol

#164
post #115

Earlier quoted context omitted.

But what happens when thieves steal my phone? How do I authenticate then? Most places use SMS as a backup, which gets us back to the original problem. People with popular YouTube accounts have to deal with this all the time and the advice right now seems to be to buy a burner phone on a false name[1] and never share the phone number with anyone, which is just crazy. [1] Fraudsters are able to convince phone employees…

Easier: register with an SMS-enabled VoIP provider, like Twilio or voip.ms, and use said virtual SMS number as your 2FA. Rather hard to steal. You can then set the service up to forward received SMS messages to your regular SMS number—but, if your phone is compromised/stolen, you can go back to the account and immediately turn off this forwarding. --- Sadly, this approach reduces the security back to single-factor, s…

> Sadly, this approach reduces the security back to single-factor, since you get into the SMS account with something you know, rather than something you have.

I don't understand why Google Authenticator is supposed to be so conceptually different from a password. The codes it provides are a deterministic (and public!) function of a code shared between you and the party you're authenticating to. Or in other words, it's exactly equivalent to a password.

When I set up 2FA on github, they gave me a code to put into Google Authenticator, and also a bunch of "one-time reset codes" in case I lost my phone. Why wouldn't I just record the original code in whatever place I'm supposed to store the one-time reset codes?

Re: Thieves drain 2FA-protected bank accounts by abusing SS7 routing protocol

#165

Earlier quoted context omitted.

But what happens when thieves steal my phone? How do I authenticate then? Most places use SMS as a backup, which gets us back to the original problem. People with popular YouTube accounts have to deal with this all the time and the advice right now seems to be to buy a burner phone on a false name[1] and never share the phone number with anyone, which is just crazy. [1] Fraudsters are able to convince phone employees…

Typically, you are asked to print out backup codes when you enable 2FA. In addition, you could copy these backups codes into your password manager and sync your password file with multiple devices, so whenever one device is gone you can access all your passwords, including 2FA backup codes from other devices.

[deleted]

Re: Thieves drain 2FA-protected bank accounts by abusing SS7 routing protocol

#166
post #63
post #15

Banks here in the UK use your chip & pin based card as a second factor (or rather, as the two factors - the chip you have, the pin you know) - they give you a little card reader that can use the card and pin to provide a 2FA token for logging in or sign requests to send money. It's a much better system. Of course, some banks don't use it to it's full potential - many use it only for signing money transfers, but it's…

In the US they have finally started rolling out chip-based cards. However, there's no PIN needed if you run the card as credit, defeating much of the security.

Not from the issuer's perspective. They're mostly interested in combating forged cards, not stolen ones, because the former accounts for the majority of their losses.

Re: Thieves drain 2FA-protected bank accounts by abusing SS7 routing protocol

#167
post #158
post #35

Earlier quoted context omitted.

SMS as a 2nd factor represents an engineering trade-off. Prior to its introduction, the only people who had access to 2FA were people who got $60 tokens from RSA. It blocks against certain classes of attacks, but is vulnerable to others (like malicious or insecure carriers). Now, Apple users can use their fingerprint as a 2nd factor (e.g. for Apple Pay), but fingerprints have the unfortunate property of not being rot…

> fingerprints have the unfortunate property of not being rotatable if compromised Coworker has a wonderful term for this. He calls fingertips "amputationware". It really drives the point home. But there is another very good reason to avoid fingerprints auth methods. The scanners are by design doing some level of fuzzy matching, so if/when[0] someone finds a way to generate an input that reproduces the signal pattern…

Yeah - I was going to saw something about people with extreme eczema suffers (Which I happen to be one), can have issues with skin just splitting open on tips of the fingers. This is the reason I don't use my finger print scanner on my phone...

Re: Thieves drain 2FA-protected bank accounts by abusing SS7 routing protocol

#168
post #115

Earlier quoted context omitted.

Easier: register with an SMS-enabled VoIP provider, like Twilio or voip.ms, and use said virtual SMS number as your 2FA. Rather hard to steal. You can then set the service up to forward received SMS messages to your regular SMS number—but, if your phone is compromised/stolen, you can go back to the account and immediately turn off this forwarding. --- Sadly, this approach reduces the security back to single-factor, s…

> Sadly, this approach reduces the security back to single-factor, since you get into the SMS account with something you know, rather than something you have. I don't understand why Google Authenticator is supposed to be so conceptually different from a password. The codes it provides are a deterministic (and public!) function of a code shared between you and the party you're authenticating to. Or in other words, it'…

I don't know how google 2FA is implemented, but I'd just assumed the initial code is akin to something like an initialisation vector / nonce for a counter or CBC mode block cipher. With the counter being 'time', meaning the scheme works something like:

hash_fn(concat(IV, time)) -> func(somehash) -> [code seq. 1]

Then on the next round the IV is discarded and it becomes:

hash_fn(concat([code seq. 1], time)) -> func(somehash) -> [code seq. 2]

That's almost certainly an over-simplification / wrong; it doesn't seem very secure to just use the previous output as the IV for the next round. Maybe it chains all previous outputs together somehow, IDK. I should probably research this, given how much I rely on 2FA for security.

EDIT: The Wikipedia article on TOTP seems to suggest that you're right; the initial shared secret looks indistinguishable from a password (although the article is a bit vague): https://en.wikipedia.org/wiki/Time-based_One-time_Password_A...

Re: Thieves drain 2FA-protected bank accounts by abusing SS7 routing protocol

#169
post #157
post #147

Earlier quoted context omitted.

I found that strange as well. Chip and signature, or swipe and pin are the common options. Both miss the entire security aspect of chip and pin.

As with all strange things, they can usually be explained by incentives. Banks get paid far less interchange rates for Chip & PIN than they do signature. Thus the system we have. So some banks can skim an extra .5-2% off the top of every single transaction in the US.

> Banks get paid far less interchange rates for Chip & PIN than they do signature.

This only applies if the PIN is being used for debit. I have two credit cards[0] that are issued by US-based financial institutions and, when the chip reader is equipped to do so, result in a prompt for a PIN when used. The interchange rate is as a normal credit card.

The bigger issue, as has been explained to me by two people I know who work in payment tech, is that credit card issuers in the States are utterly panicked by the idea of doing anything that might result in even a small fraction of a percent of their cardholders switching to another card. PINs are seen as inducing friction or a previously-unknown step into the payment process (since US customers have been conditioned for 20 years to "enter a PIN for debit" and "sign for credit"). To now change to PIN-primary cards would result in confused customers, higher support costs, and plenty of customers switching either to another credit card or to (the horrors) another payment method entirely, like cash. So the theory goes, anyway. Therefore, US banks are loathe to introduce cards that can be verified by PIN at all, much less ones that are primarily verified by PIN.

0 - They are not debit cards with VISA or MasterCard logos; they are actual credit cards accessing a line of credit. One comes from the State Department Federal Credit Union and the other from First Tech Federal Credit Union.

Re: Thieves drain 2FA-protected bank accounts by abusing SS7 routing protocol

#170
post #3

Earlier quoted context omitted.

Yep. Everyone has been saying SMS is not a secure channel for forever now, and this is only one of many possible attacks that can be used to trivially bypass SMS based auth. It's sad but true that in general banks have some of the weakest security on the internet, most online games do a better job protecting user accounts from unauthorized access.

The banks didn't get the memo from NIST and if anything they are getting worse - they are actually ramping up their use of callback and SMS authentication. Last month I had several apps force an SMS authentication because I hand't logged in since paying bills the prior month. One app disabled Touch ID and forced an SMS auth before I could log in again. One bank locked me out of my account entirely because you can't l…

> One bank locked me out of my account entirely because you can't log in or contact custom service without receiving an SMS code (no voice option), but their system refuses to send SMS to my number.

I have this problem with one of my credit card issuers (not the two I mentioned elsewhere in this thread) and they're going to lose me as a customer as a result. I can't log into any online banking without receiving a phone call or SMS and I'm prompted to enter a number at which I can receive such a thing. The problem is, I am entering the number that I know the bank has but entering that number--or any other number I own--is met with "hmm, it doesn't look like that number belongs to you." Of course it doesn't considering my mobile phone service is paid for through my LLC and this is a personal credit card account.

When I tried calling them, I'm told that, again, I need to verify myself with an SMS and, no, the number I have used for a decade is not sufficient.

At least they've now returned to mailing me paper statements. Once I've verified that my last automatic payment has moved away from them as of next month, the card gets canceled. If I can't cancel by phone, I'll cancel by mail. If I can't cancel by mail, I'll just leave it in a drawer and watch my mail for any new statements until the card is canceled for inactivity.

Post reply on HN