I may get down voted for this and so be it, this must be said. This is a prime example of creating what was intended to be a security feature without understanding the threat landscape. I just tested it, and it's 100% vulnerable to caller ID spoofing. In 2016, caller ID spoofing is as simple as downloading an iPhone app and spending $30 for a bunch of minutes.
The problem is, a lot of people will find this cool and will also not evaluate the threat landscape. In fact, it's even worse. They will assume the threat landscape has already been evaluated. The code is out there, so it must be good. They will then implement this into some "super duper secure" service which should require a far more security for user authentication. It will then take me 15 minutes of pulling my hair out in a security review to explain to whomever implemented it that it offers no security. The team will walk away from our meeting wondering if I was just trolling them and ask how their entire team could have made this mistake. They will then come to the conclusion they are smart and I must be wrong. They'll then call me back to explain again, at which point I'll take them through a full video demonstration with their VP of operations on the call. This time they will actually "get it" because they saw it exploited on video. Their VP of operations will then fire the project manager and lead developer and I'll feel like shit for being responsible for the termination of two careers.
Not to mention that it's incredibly inconvenient if you don't carry a phone, or if you lost it. I tried to signup for airbnb this weekend while traveling, but wasn't even able to go through the verification process without a physical phone. Zero alternatives for verification and even trying google voice (my main 'phone' provider) wasn't good enough. Sure, I could've borrowed someone's phone for a second, but isn't that the sort of thing these systems are supposed to guard against? I don't get it.
Another example - you can't use uber on a desktop without going to m.uber.com last I checked. There's no way to order trasnportation without that m. (why!)
Another - gmail. You either need another email or a phone, and at the time, neither were possible. (why!!)
For tons of reasons, I just don't like having a phone in my pocket 24/7/365. Mostly, I just enjoy the peace of mind of being unreachable. I've been oncall for years, but that oncall vibe is extending more and more into social situations, for the worse. I hate it. Devs - PLEASE account for those like me! I'm really tired of people telling me (accurately :(.) "You wouldn't have these issues if you had a phone." on account of your laziness or lack of awareness for sensible security.
I have a shocking number of burner phones driven by the need to register for stuff which requires phone-call validation of identity. Of course every one of those phones was purchased in cash while wearing a hoodie and sunglasses, after parking in a nearby neighborhood and walking to the store.
Note, I'm not a criminal, I just play one in my day job.
I might go that route, honestly. I've done a few security disclosures recently as myself and doing so has been giving me a vibe that I'm not a fan of. Same with a lot of the FOIA calls I need to make. Having a burner phone might help, as much as I'd hate to use it.
It's relatively easy to change/fake the caller ID of phone calls so unfortunately this approach isn't really secure. That's why phone number verification usually places an outgoing call, to verify that you're actually able to receive calls on that number.
This has been the case since I was a kid. My dad told me that I could verify[0] the identity of a caller by calling back to a number that was known to belong to the entity in question.
[0]: for some level of security. My father was a farmer at that time and I know he wasn't talking about a nation state adversary ;-)
My SIP provider passes whatever number I send, for most of the numbers. No talking to them required. Particularly fun for Android phones that do Google Maps lookups for caller ID, so calling from 2024561414 shows up as "The White House"
Just for fun i went ahead and verified 2024561414 with the demo of this thing. It gave me a nice little check mark showing that I was definitely the White House
Sorry, what's an SIP provider? I've looked it up and still don't understand what it is. Is it a residential service? Can anyone get it? Is it some form of VoIP? Or a classical phone line? I've seen it in multiple places but don't understand what it is or which companies it relates to.
It's used in many places, but mostly offices. An office might have an exchange system, with features like voicemail and routing different types of call over different networks.
I have a personal account which gives cheap international calls, which I added to my android phone. I can receive calls at my SIP address, from anyone on any provider. When I make a call, I'm given the option of using the mobile network directly, or SIP.
Naturally, neither the phone networks not the big tech companies want you to use SIP. They'd rather you used normal calls, or their proprietary system.
Can you recommend one that works well? I want one that hopefully provides a Greek DID, I want to be able to make calls from my Android to landlines over my home Internet connection, as you describe, but I haven't managed to find a good (read: cheapish) provider.
I use voip.ms but many others exist. Anveo, Twilio, Vonage, etc. cheapest might be a service that uses Google, but only for as long as Google offers free calls.
And there are various providers which will let you do 'trunking' into the phone system, so you can have any number of handsets with the same origination number appearing on outgoing caller ID.
What's known as "caller ID" is just an add-on that phone companies glued onto the system to have a feature to sell to the public. Another such feature is ANI[1] which was originally meant for billing purposes but is a feature sold with toll-free (800) numbers. It is much harder to spoof, but even ANI is not guaranteed to be present.
I would really love to hear a telecom engineer explain why the true origin info isn't accessible to the called person. A telephone call is a two-way connection -- the path in both directions must be known otherwise you won't have a two-way conversation.
A telephone call is not email or an old-fashioned letter. Both of those are one-way communications, so if the intermediaries don't carefully track the email or letter as it progresses through the pipeline, you have spoofed email or untraceable letters.
But at the lowest level of the telephony protocol, the true and correct path to the originating caller has to exist. Otherwise your voice won't travel to the other person. I'm curious to know why that really deep reverse route has never been made available to public (as an API or a purchasable feature or in any other form).
> I would really love to hear a telecom engineer explain why the true origin info isn't accessible to the called person. A telephone call is a two-way connection -- the path in both directions must be known otherwise you won't have a two-way conversation.
Telephone isn't really like IP routing. If D wants to call P, the connection might get set up like this:
D -> K -> H -> V -> P
P only knows that they are speaking to V, and D only knows that they're speaking to K.
See what happens is D sends a message called "Call Request". This creates a channel id (D,C1) between D->K. K will then create it's own "Call Request" with it's own channel id (H,C2) which tells H to bill K for this call. Only K will know both the channels C1 and C2 and will bridge them internally. When H makes a "Call Request" to V, it has it's own billing arrangement with V and they agree to simply count calls, so H doesn't actually forward anything except the channel id (nil,C3). V gets away with this because the wire is clearly marked with "K TELEPHONE INC". Eventually P gets an "Incoming Call" message with it's channel id (P,C4), and can accept the call or reject it. If he accepts it, then each party will send "Accept Call" messages back down the chain.
These channel ids are used to actually carry the phone call (or data packets, or whatever).
"Caller ID" isn't the "source of the message", just some data transmitted along with the ringing sound, and as you can see the circuit doesn't have a globally unique identifier. If someone doesn't transmit who to bill, then nobody will get billed for that call (and maybe nobody will be!) but V doesn't want to send bills for this call all over the country so V only sends bills to a few carriers and its own customers.
All the bills have the "correct calling numbers on them" because of some extra billing data that's included in the call. This billing data might be omitted (the bill says "NUMBER BLOCKED"), and it clearly isn't required to establish the call. People can ask their phone company to ignore calls that have a blocked number.
Phone companies used to trust each other not to spoof this information, and now that calls from certain numbers aren't usually billed differently than from any other numbers, this doesn't cause a problem with billing -- only with people who seek to use "making a call from" an authentication method.
>"Caller ID" isn't the "source of the message", just some data transmitted along with the ringing sound, and as you can see the circuit doesn't have a globally unique identifier. //
The companies could enforce the side channel info as the actual call origin, but they don't want to. Just like snail-mail spammers they're paying more money than residential customers will pay to require that info.
It's broken because it serves the purposes of the phone companies to keep it that way. This is what you get by detaching profit from ethics.
I'd settle for my phone company dropping calls with spoofed caller ID - like 0, my own number, foreign calls with local numbers, local numbers that don't even terminate, etc..
Indeed I think origin should be legally required even if it's "K phone network" - I don't mind blocking all calls via companies that service spammers.
That you say it easily doesn't mean that it's easy to do.
The current telephone infrastructure wasn't designed. It grew: Verifying a call would involve either tying up an additional channel back (doubling the cost of the infrastructure), or replacing (parts of) the infrastructure with something better designed- like a TTL "ping" packet going backwards to verify the route on the original channel. Getting everyone to change their hardware is hard. Just look at how long it's taking to get IPv6 out.
Fortunately, tracing a call isn't like television: You do not have to "keep him talking". You can ask the phone company to research the calls made to your number at a specific time, and in the process of reconciling billing, the phone company can find out, and then you can use the judicial arm to deal with people who spoof the calling number.
I'm not specifically wanting call verification I'm wanting them to detail origin if they have it (they can use the callerID field to forward that information to me) or to refuse to route calls that are clearly spoofed. If the callerID is 0 then the phone company knows it's spoofed and can block it, but they don't get paid for that - that's the only reason I can come up with for them to forward calls that have certain incorrect origin information. At least when I look at the callerID display and it says my number I know that it's not possible that call is anything other than spam - why would a company choose to forward such calls if not for the money they get for doing so?
>You can ask the phone company to research the calls made to your number at a specific time, and in the process of reconciling billing //
Are you telling me that at the point the company decides to carry a call from an external source they don't know if they're going to be able to bill that company for the call? Surely they know the network origin of the call - they at least know the hard infrastructure it's arrived at their periphery from, they have to right?
So when I get a foreign call centre spammer on the line the company knows at the very least that was forwarded to them from, let's say, France Telcom [made up example] and could give me that info in the callerID field.
> I'm not specifically wanting call verification I'm wanting them to detail origin if they have it (they can use the callerID field to forward that information to me) or to refuse to route calls that are clearly spoofed.
The phone company that provides you service simply does not have this information at the time of the call. They only know for certain who to bill. Changing this requires replacing a lot of deployed equipment.
Furthermore, it is already illegal to spoof caller ID in the USA[1], and the UK[2] and elsewhere.
You can indeed tell your phone company to reject calls without caller ID, and indeed from various switches. If one gets through, you will need to note the time that you received the call and file charges with the authorities.
The phone company will then research the call, and produce for law enforcement who in fact made the call.
> If the callerID is 0 then the phone company knows it's spoofed and can block it, but they don't get paid for that
You are confused: The callerID field (aka "presentation number" in the UK) is in-band and transmitted by the calling station, the billing field is out-of-band and transmitted by the receiving station's "next hop". It is also not normally presented to the callee, although with a special kind of connection you can receive it.
> when I look at the callerID display and it says my number I know that it's not possible
You should contact law enforcement. This is a crime.
> Are you telling me that at the point the company decides to carry a call from an external source they don't know if they're going to be able to bill that company for the call?
Yes.
Your phone company doesn't bill the caller. They only bill the other phone company that handed them the call.
> Surely they know the network origin of the call
The "network origin of the call" as you put it, is the phone company that handed them the call. It is not the person who dialled the number.
Even if all of the phone companies are really one (limited) company, the individual switching offices don't send this information down with the call for efficiency reasons.
> So when I get a foreign call centre spammer on the line the company knows at the very least that was forwarded to them from, let's say, France Telcom
No. "The company" only knows the company that switched them the call. It takes research to work out who actually made the call that is normally distributed by separate offices because it's more efficient.
Nice speech, but creating a new side channel on the PSTN is really hard to do. It requires standardization and the coordination of telcos, operators, device manufacturers, world-wide, many of which only have partially digital networks. (Think about how hard it would be to add a new field to TCP.)
In business telephony systems there is no "true" phone number for a customer.
The telco has some connection to a customer site which carries signaling data and N concurrent voice channels. A potentially large block of numbers are routed down that link by the telco. When he customer makes an outgoing call it sends whatever it wants (or nothing) as CID.
A national franchise with 1,000 stores serviced by 30 different small town telecoms might all send the national HQ number as caller ID, even though the calls do not jump through the national HQ first.
There is no will among the various telecoms to build and integrate a whitelist system that interoperates, so they leave it wide open.
You can't just find out who a phone number belongs to, and phone numbers do not have to ring to anyone on the other side to be valid outgoing CID numbers. It's unclear how such a whitelist system would help anyone, anyway.
Outbound traffic (placing a call) is entirely separate from the inbound path. This is similar, in a way, to IP. You can send a packet with any source IP from basically anywhere on the Internet. The difference is that with IP, any return packets are routed separately, to the source IP. With a call, return voice just goes along the established channel. Each provider along the way will know who they received the call from, but cannot verify that the number belongs to them.
This is by design and used in many cases. Call forwarding, for instance. Or even just the basic case of using multiple providers to route outbound calls. Some might be cheaper than others, so you need to select on a call by call basis. Also, think of international calls. How is Idaho Telco XYZ supposed to be able to verify that this call from Zambia really belongs to ZambiaCom XYZ? And vice versa.
Also note that there's simply no requirement to even having a number. You could just be placing outbound calls (like SkypeOut). Or no one to one mapping: an office sharing one number for outbound calls, or a single telemarketer changing numbers call by call as they dial for different customers.
All it would take is providers refusing to connect to anyone that supports spoofing. Let users report spoof calls, then blacklist those providers. Everyone will fall in line real quick. (You could also just fine them for each spoof, not cut them off completely, but enough so they won't want to offer it a service to their customers. Also, of course you announce this months in advance so everyone has a chance to stop supporting it first.)
Call forwarding is fine as long as the spoofed number is also associated with the caller. But anyone that lets people call using a number that's not theirs at all should be booted off.
I switched to a different SIP provider as they were cheaper, but my number was still held at the old SIP provider and couldn't be ported. I explained the story and asked if they could 'virtually' add that number to my account so outgoing calls would come from that number. They just switched on the feature to enable me to set the caller id to anything as it was easier for them.
This is also a fun attack. Find a provider that does this. Request to port a target number (a bank or an escort service or whatever). Port will stall for a bit, in the mean time, the service provider activates your number internally, so their own dialers route to their "version" of the number.
Now you get all the calls from that provider to that number. Forward them to the actual destination (using an unrelated provider) and no one will notice for a while. Except, you get all the calls and media.
Most VoIP providers let you use any number as the caller ID with a simple SMS verification. So, if you were to have access to someone's phone for a few minutes you could possibly verify it and use the number for making calls and sending text messages from the VoIP service.
I believe the SMS verification is something that companies use to avoid liability alone, technically they can use any number as the caller ID if they choose to.
I've worked in VOIP quite a bit, and even built a product based on the fact you can fake caller id over SIP i.e. "keep your number but lower your outgoing call rates"
As great at this probably is, I don't think adding yet another dependency to facebook is a good thing.
I'm getting tired of services that only accept facebook users.
Having a facebook login or any other facebook service requiring the user to be a facebook user is not bad in itself (and can be pretty useful), but it should _always_ have an alternative.
That's why I think projects like Dial2Verify Twilio are a great thing. They're still not perfect though, as some said here on HN.
Are you willing to make international users pay up to 80¢ per verification? If someone cancels a call, I still have to pay for one minute (it's only free if I cancel the call). So if I were to call any American number that hung up on me, I have to pay 80¢ (USD dollar cents of course).
Just pay the 0.02¢ or whatever phone services charge these days. If your business is actually big enough to have to worry about phone verification, do it right. Users don't like to call your number since they don't know the costs associated with it (especially international users).
Furthermore, it makes number spoofing much harder.
Haha, this is the digital version of the Indian phenomenon of 'missed calls', used as 1-bit 0-cost notification mechanism. It's become such a cultural artifact, that big companies are now advertising numbers you can 'missed call' and get a callback from.
It's not Indian specific either. I've seen it in a number of places throughout the world. It works anywhere that does not charge to receive calls (i.e. any sane place outside of the U.S.A.) as long as the caller doesn't get billed for cancelling.
You can get more than 1-bit of information as well if you sync the clock on your phone with the recipient. That gives you approximately 3.3 bits of information if you use the minute modula 10. This only works if you previously agree upon a meaning for values (Mod 0: Yes, Mod 5: No, etc).
Those of us old enough to remember AT&T before the breakup probably had a similar system with our parents. Call, let it ring once and hang up. Repeat. Wait for mom to call you on the family phone.
Would 'rejecting' the call result in the calling user's operator billing them, though? This is a major concern with international usage, given phone providers' tendency to... overcharge for what's technically VoIP usage.
The classical text message verification schemes barely have this issue in most of the world as the recipient pays nothing, but of course the sender gets billed instead.
This doesn't reserve the incoming number for just that user (given that one has to enter their phone number beforehand), but while the user is using the line, other users most likely wouldn't be able to call either (though it might be Twilio handles this as well and sends a status message anyway - as even cell carriers seem able to notify users of incoming calls while being in a call already).
Well done. But you didn't blog about it, or release that part of your app as a standalone library. You also didn't (couldn't) patent it - it doesn't need to be new to be interesting and valuable to HN readers.
The problem is, a lot of people will find this cool and will also not evaluate the threat landscape. In fact, it's even worse. They will assume the threat landscape has already been evaluated. The code is out there, so it must be good. They will then implement this into some "super duper secure" service which should require a far more security for user authentication. It will then take me 15 minutes of pulling my hair out in a security review to explain to whomever implemented it that it offers no security. The team will walk away from our meeting wondering if I was just trolling them and ask how their entire team could have made this mistake. They will then come to the conclusion they are smart and I must be wrong. They'll then call me back to explain again, at which point I'll take them through a full video demonstration with their VP of operations on the call. This time they will actually "get it" because they saw it exploited on video. Their VP of operations will then fire the project manager and lead developer and I'll feel like shit for being responsible for the termination of two careers.