Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

arstechnica.com

Post reply on HN
Print view View original

211–220 of 225 posts

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

#211

Post by Natanael_L »

Latty wrote: 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…

There's one bank I know here in Sweden that does the same with cards + reader, ICA Banken. Most others use dedicated hardware tokens.

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

#212

Post by tptacek »

city41 wrote: post #210
tptacek wrote: post #209

Earlier quoted context omitted.

I agree with Maciej here: the stock message board "I'm too smart to leave any advice unchallenged" attitudes on these threads are doing a lot of people who face serious risks a lot of harm. If you know what you're talking about and have a serious concern about this kind of advice, by all means present your argument. But if you don't, find another way to learn.

What the actual fuck? I didn't present any advice whatsoever . I merely asked why the guide recommended a backup of Google Authenticator.

And now you understand, right?

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

#213

Post by Natanael_L »

alasdair_ wrote: post #117
cbhl wrote: post #42

Earlier quoted context omitted.

So long as you never switch or factory reset phones, because Google Authenticator, by design, never reveals the private keys. (I've locked myself out of accounts because I broke my phone and had to get a new one.) Also, do you really trust your Android phone with your TOTP private key? How do you know there isn't malware running on it as root?

I use google authenticator along with a printed list of recovery codes. Half are stored in my safe and half in another location offsite. I own a yubikey but it's useless as a permanent device since it needs a fullsize USB port - something my phone (and the latest gen macbook) lack.

They have a new USB C equipped version

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

#214

Post by thaumasiotes »

acdha wrote: post #185
thaumasiotes wrote: post #164

Earlier quoted context omitted.

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

The differences from a password: 1. Not shared across sites 2. Guaranteed minimum length 3. The portion going over the wire cannot be used more than once or after a few seconds 4. The phone app doesn't expose the seed or allow you to copy it off the device. Running on iOS has strong guarantees against access by other apps. That's not perfect and U2F is a huge improvement but it's safer than SMS and given the number o…

Only your third point is actually a conceptual difference from passwords. In terms of the common idea that 2FA should be "something you have" plus "something you know", a TOTP seed is "something you know", not "something you have", but everyone talks as if the opposite were true.

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

#215

Post by Nexxxeh »

voltagex_ wrote: post #150
derefr wrote: 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…

A lot of providers will block VoIP and SMS gateways being used as verification (see PayPal for an example).

There's a guy that does an SMS to web gateway with real telephony hardware. You pay by bitcoin and its accessible over TOR. You pay, he pops in a topped up PAYG SIM. You have a real mobile telephone number.

You can run your own private one at home with a Raspberry Pi/ttl serial adapter and a cheap SIM module. Or use a dongle.

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

#216

Post by m-p-3 »

kevin_b_er wrote: post #4

SMS is not a secure 2nd factor. It is subject to not only technical attacks such as the one in the article, but also a wide variety of social engineering attacks. Getting cell phone reps to compromise an cell phone account is apparently not hard, and has been used many times to take over online accounts.

Exactly why NIST declares that sending 2FA codes over SMS is insecure and should be avoided.

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

#217

Post by phil21 »

techsupporter wrote: post #169
phil21 wrote: post #157

Earlier quoted context omitted.

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

Interesting, I guess I always thought this applied to credit as well, just not as drastically. I stand corrected.

> Increased revenue: In the US, the different in interchange rates between PIN-based debit and signature-based debit transactions can be substantial for larger dollar payments. Although Regulation II (a.k.a. the Durbin amendment) caused the card networks to reduce debit interchange rates for the largest card issuers to just 0.5% plus $0.22, this still results in interchange of about $0.72 on a $100, signature debit purchase. The same PIN-debit purchase might generate about $0.25 and possibly less in a area where there's substantial competition between PIN-debit networks. To be fair, this isn't true for credit card transactions (since there is effectively no such thing as a PIN-based credit card transaction in the US today and therefore no distinct interchange rates for PIN-based payments) but is does explain why there might be a general preference not to proliferate the use of PINs as the US card population and terminal base is converted to support EMV.[0]

[0] - https://www.quora.com/Why-is-the-USA-adopting-chip-signature...

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

#218

Post by scrollaway »

StavrosK wrote: post #171
tony101 wrote: post #152

Earlier quoted context omitted.

Have you tried using a (free) Google Voice number for 2FA purposes? Google Voice has no/minimal customer support, so it should be almost as secure as your Google Account.

Haha, I love the reasoning there. I haven't, but you're right, I should.

Well if you manage to do that, let me know. To my knowledge creating a text/voice compatible Google Voice number is not possible in europe.

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

#219

Post by rocqua »

bkor wrote: post #179
alasdair_ wrote: post #113

Earlier quoted context omitted.

>defeating much of the security. In many ways, this is better, since a skimmer can't grab my pin and credit cards have rules where they must immediately refund fraudulent purchases, while debit cards are often much more difficult to reverse.

Your PIN being skimmed is refunded in The Netherlands without any problem. They usually use the combination of the magnetic swipe and your PIN. Restricting bank cards to just EU reduced this fraud to around 15% of the original amount. See https://www.rtlnieuws.nl/nieuws/binnenland/skimmen-met-80-pr... . This was implemented around 2012.

In the Netherlands, magnetic swipe has basically been phased out. You are now supposed to use the chip (and obviously still PIN). I think this happened around 2014, basically, the 'swipe' part of almost all readers is now blocked by a sticker that instructs you to use the chip. I'm not sure if the sticker can be moved in case you really want to swipe.

Tap-payment is also being rolled out quite rapidly. It's about 1.5 years old and I'd say I now tap for 70% of all transactions.

The move

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

#220

Post by acdha »

thaumasiotes wrote: post #214
acdha wrote: post #185

Earlier quoted context omitted.

The differences from a password: 1. Not shared across sites 2. Guaranteed minimum length 3. The portion going over the wire cannot be used more than once or after a few seconds 4. The phone app doesn't expose the seed or allow you to copy it off the device. Running on iOS has strong guarantees against access by other apps. That's not perfect and U2F is a huge improvement but it's safer than SMS and given the number o…

Only your third point is actually a conceptual difference from passwords. In terms of the common idea that 2FA should be "something you have" plus "something you know", a TOTP seed is "something you know", not "something you have", but everyone talks as if the opposite were true.

Think about it a bit longer:

1. Passwords are selected by the user; you cannot prevent reuse. While it's technically possible that a site could allow you to set the TOTP seed nobody does.

2. Password entropy is notoriously hard to calculate programmatically – e.g. well known movie passwords or leet-speak are often judged as stronger than shorter true-random sequences – but you generate the TOTP seed.

4. As with #1, preventing reuse is hard. Knowing that all extent implementations offer fairly strong protections against accidents is a key difference.

Your finally point depends on how you judge the whole system: “something you know" can be told to someone else, which isn't true of TOTP. It's also always valid and reusable whereas the one-time code is closer to an on-demand verification. From the perspective of security boundaries, a desktop user accessing a separate token, phone, or arguably even an iOS user using a separate app is closer to something you have than something you know.

TOTP isn't the strongest form of MFA but it's closer to that end of the spectrum and, especially in consumer contexts, a huge improvement over nothing. In the real world, those kinds of security improvements are still meaningful even if they're not perfect implementations of a textbook concept.

Post reply on HN