Hacker News Reader

Comment by josh2600 | Hacker News Reader

This is a feature...

This is basically a lookup which authenticates users based on caller ID (the password is the ssn). This is the same as when your carrier changed your voicemail password to be your phone number (and self-authenticate on inbound calls).

The problem everyone is looking at effects 100% of customers but the bank (mistakenly) believes the barriers to entry are high.

The important takeaway is this: You cannot have a secure service that is authenticated with a phone number.

Phone numbers have been, and will continue to be, an invalid source of identity. In fact, considering a phone number as a signaling agent in a Web of Trust is a terrible decision to make. Time and again we hear of these exploits which wouldn't happen without terrible assumptions.

PSA: YOUR PHONE NUMBER IS SPOOFABLE; IT TAKES 10 SECONDS. DO NOT BUILD SYSTEMS THAT TRUST YOUR PHONE NUMBER AS IDENTITY.

View on HN

I am no expert but I think the problem is assuming that the caller ID of the incoming call to the bank is authentic.

I'm curious if you could break a similar system that assumed that receipt of an outgoing call made to the customer's phone number was validation of identity.

Well this depends on delivery medium. If the outbound call is routed to a SIP URI instead of over TDM, you actually have no idea where that calls going.

A DID (direct inbound dial) is physically punched down into an exchange somewhere near the actual physical area (415 exchanges are physically punched down in or around San Francisco, for example). If calling a specific DID results in a forward to a carrier like, say, bandwidth.com, then the routing commands applied after that would not be traceable (or at least not easily).

In short, only if you know the method of delivery, and I'd argue that it's virtually impossible to know what kind of routing a number you're calling will trigger.

Does that help? Inbound caller ID is just Fubarr'd because you can fake it in two seconds.

Outbound call to a number is harder to break. One way is to port the number to another provider, illegally. If you have the person's information and bill, you probably have enough info to get the line transferred. And sometimes, providers will accidentally/idiotically allow a number to be ported even if the information isn't correct; there's plenty of room for mistakes.

Another attack is to target the way they place the outbound call. Suppose they place the outbound call with provider X. An attacker might sign up and start a port via provider X. If provider X has poor code, they might activate the number internally, and route all their customers calls to your account, before they find out the port's been rejected. Or you might be able to compromise the provider another way - many providers and VoIP software systems are hilariously weak on security.

The first attack will work across the entire phone network; the second requires the authentication call to be made via an insecure provider.

Right but you're talking about owning the DID, which one may or may not need to do in order to compromise your connection. For example, if I pwn the Asterisk box your call routing runs through, I can mirror the audio or redirect the audio pretty trivially.

Going a step further, given how few people aren't buying through a reseller, it's possible to pwn an upstream provider and impact boxes through a man in the middle attack. Even over TDM you're not safe because of physical taps which are difficult to detect (albeit easier than IP).

No, Phone numbers are not secure and should never be used as a form of authentication. You don't even need to port a number, you just need to be somewhere in the stream.

I think there's a significant scope difference in performing a MiTM attack (via hacking a provider or installing a tap) and forcing a port through.

After all, it's implicit in telephone banking when you authenticate via voice that you trust the connection. The argument you're making is that telephony is insecure, which is arguably true, but sorta irrelevant within the scope of telephone banking.

How is it irrelevant? Is it not the crux of the issue here?

Many upstream providers are just Asterisk boxes forwarding traffic. Those boxes can be overloaded with a malformed SIP header; hell, most application switches get wrecked by malformed headers.

What I'm trying to say is that money is one of those things where security is actually important. Trusting telephony, even as a signal and not source, is foolish. There are many better methods of deriving identity.

My point, and arguably the point of the article, is that telephony is insecure, and I think it's pretty far from irrelevant... Please correct me if I misunderstood, I'm not trying to offend I just don't understand.

>I'm curious if you could break a similar system that assumed that receipt of an outgoing call made to the customer's phone number was validation of identity.

That would certainly defeat the caller-ID spoofers. "Please hang up now. We will call you right back ...". Receiving a call from the bank's automated service out of the blue would also alert you to the fact that hackers are attempting entry via spoofing. Or are phone-phishing for whatever details the automated system requires in order to proceed.

Google now offers two-factor authentication for its accounts. You sign in with your username and password. Then Google texts a random code to your phone, which you enter into a third dialog. That way, the bad guys have to steal your phone in addition to your password.

Google two-step: http://www.youtube.com/watch?v=zMabEyrtPRg

> Then Google texts a random code to your phone, which you enter into a third dialog. That way, the bad guys have to steal your phone in addition to your password.

Nope, they just need access to your phone account at the carrier.

In the case of an AT&T business account, it's just your EIN from the IRS and the billing address of the company.

Then they just pop the "replacement" SIM from AT&T in their burner and receive the text message.

Sure, it's harder than just stealing a password. But don't think it requires stealing your phone. It's just one more account that needs hacking.

You'd need to get the encryption keys to burn that SIM if it should work. You can't extract those from most SIMs(Then again if steal the original SIM, you don't need to clone it). The other option is to hack the network node where it's stored, which should be a very different place than the main account data - it's normally a lot harder than stealing a phone.

You misunderstand me. I am talking about walking into an ATT store and having them issue a "replacement" SIM for the account. No SIM hacking necessary.

It is fraud, however. But so is lying to a bank IVR.

Wouldn't it be fairly trivial to have an automated system to call the caller back (Verify that they aren't spoofing the caller ID)?

  1. Caller phones in
  2. System looks at caller ID, and says "We will now call
     you right back to verify you are who you say you are"
  3. Caller hangs up and has to wait for call.

Surely that system would need a much higher level of hacking to be able to intercept the call.

This is not implemented for one simple reason:

Outbound calls are more expensive than inbound calls.

The usability issues that T-hawk mentions are more of a reason.

And anyways, inbound on a toll-free number is often pretty close to your outbound rate, for the US.

That's just not true. The inbound rate on Toll-free is almost always higher than outbound termination. Only in rare, high-volume circumstances is Toll-Free inbound cheaper than outbound.

Usability is a huge issue, but I think that it comes back to the bottom line cost figure. The usability is just one of those problems that no one wants to start to deal with because of the cost. If outbound was cheaper someone would've found a way to do it (IMHO).

You may want to re-read your comment. If Toll-free inbound is higher than outbound, then why wouldn't they do outbound more often? We're talking about (in many cases) businesses like banks which offer toll free numbers. So obviously cost is not the dominating factor here.

Some systems did implement outbound calling for increased security. I'm thinking dial-up (BBS/remote access) scenarios. Windows NT, for instance, allowed you to allow a user-defined or preset callback number. Although, for user-defined, its more likely a cost issue than security.

You could do that, but it would be a terrible idea and experience in practice.

1. Your system is unusable from anything that doesn't provide an accurate and usable caller ID number. Such as any office where outgoing calls route through a trunk number. Or many VOIP services.

2. You've quite possibly doubled your phone bill, or at least substantially increased it.

It's not always correct to throw as much security as possible at a system. Security always involves tradeoffs and sometimes it is correct to make them.

how does this affect systems in africa and asia where mobile banking is widespread. tons of money transfer is done by sending it via text messages. any idea how they handle this? is spoofing a text message totally different?

Reply on news.ycombinator.com