Ask HN: Carrier “lost” my number in a port request
I tried switching from T-Mobile to US Mobile after parking it on a VoIP service for a year (was abroad). They botched the port request completely. Ended up gaslighted by both companies, both claimed they "don't have the number".
Need my number for 2FA—literally can't move forward with a background check for my new job, can't send money to my family with my bank, etc. I'm sure I could theoretically get a new number but it seems the admin cost of this would possibly be in the hundreds of hours.
Do I have any recourse?
159 comments
[ 4.2 ms ] story [ 229 ms ] threadFor wireless carriers, yes. I'm not familiar with any for landlines.
Edit: https://www.fcc.gov/consumers/guides/porting-keeping-your-ph...
Looks like small providers don't have to do any porting, plus as a sibling comment pointed out, you can't port a number after you cancel service.
In fact I had a case where I switched from Verizon without moving. But Comcast’s switching gear was in a different exchange so they had to change my number.
This was a while back. There may be more flexibility today.
The rules appear to apply to "wireline" as well as "wireless" providers. I don't know if the FCC uses the term "wireline" to refer to something unexpected, but my best guess is that your experience breached the FCC rules.
There is a complaint link on that FCC page.
In particular, https://www.ecfr.gov/current/title-47/chapter-I/subchapter-B... has what seems to me like pretty strong language:
> 47 CFR 52.34(c) Telecommunications carriers must facilitate an end-user customer's valid number portability request either to or from an interconnected VoIP or VRS or IP Relay provider. “Facilitate” is defined as the telecommunication carrier's affirmative legal obligation to take all steps necessary to initiate or allow a port-in or port-out itself, subject to a valid port request, without unreasonable delay or unreasonable procedures that have the effect of delaying or denying porting of the NANP-based telephone number.
So just don't tell your current provider, the new one should be able to handle it.
If your wireline carrier hasn't been (re)absorbed into ATT, Verizon, or Frontier, it might be small enough that there's no competitive carriers in their central offices.
The number can’t be gone of course, it belongs to a range operated by a provider (where it originally came from) who can see who it is being forwarded to. But no one is under any obligation to help you with that setup. All they have to do is make a credible offer to port the number if you move to another provider.
The fact the providers provide this forwarding service doesn’t mean the costumer gets a claim to the number, which is what this article is all about. A customer angry the number was ‘taken’ from him. It was never his. The providers are required to provide the porting service but if something goes wrong and a number is somehow lost, the costumer doesn’t have a right to go and demand it back from someone. Just like when the providers renumber an area, people come and complain they have to redo their preprinted letters and the lettering on their cars. Too bad, the number is not yours.
He can go and ask to get his number back, or he can make demands and then try complaining to the FCC. But I don’t think they’ll do anything.
Numbers have generally started being recycled after a shorter rest (only a few months).
When I worked with a system handling portings it should have been possible to find where your number went.
Do you still have the physical card or the papers that came with it originally?
Try to get the carrier to file a real bug report, something that reaches the developers, with your ICCID, found on the physical card or the documentation that came with it.
Which is probably utterly useless to the OP. At this point, they probably have no real choice but to go through whatever paperwork is required to recover access to their accounts without having the phone number.
The sending carrier has that number port logged, and the receiving carrier will if they received the request.
So, what kinds of things would actually go wrong? "Bits of proprietary software yelling at each other in non-standard-ese"? Crazy scripting fixing frequent human mistakes? Or...?
I'm very fascinated with this sort of thing given it's treated like such an impermeable brick wall.
Most will require two government IDs to be sent in to remove 2FA and 1-2 week process to review & confirm.
Moving forward you should look at Yubikey where you can with the backup being your phone via Authenticator app.
It's not like it's showing any signs of going away either, financial institutions even are newly implementing it.
There are times where SMS 2 factor is worse than no 2 factor at all. Common number porting attacks allow an attacker to be far more convincing to the support staff when they call to say that they forgot the password but still have access to the second factor.
I've never heard of this. If I lose my number, can I still regain Google account access by mailing my info in?
I've encountered a similar but less problematic version of this simply by being abroad somewhere my provider didn't cover.
When you are paying customer you are also getting the privilege of contacting the support.
I think it is fair that Google does not want to directly talk to billions of people using their services and not paying a cent for it. You get it for free? It is up to you to make sure you don't loose access.
The cheapest paid workspace account is cheap enough that it probably costs less than processing a single support ticket. Remember, when you loose access you are probably looking at multiple touch points and multiple people on their side to get you back. You wouldn't want any single person to be able to just change whatever they want?
So if they allowed it, people would just pay for the privilege once to get the problem resolved and then downgrade themselves back after one month.
The issue here is that the ratio of free accounts to paid accounts is so high that if any support was allowed for unpaid accounts it would absolutely deluge the system and paid accounts would have to pay a lot more to cover the cost of support for unpaid accounts.
But I do think they could provide a paid support ticket where you can pay an amount that would cover their costs (and of course then some) for a single support request.
The issue with this is that somebody could do this to "recover" account that does not belong to them. Paradoxically, there is some extra security in not allowing any social hacking by just not allowing any manual work on the account.
That's the problem. The more flexible you are with helping a customer, especially just over a phone or computer, the more open you are to social engineering attacks. At least in the US, there are various processes involving notarized/Medallion signatures and the like. But at that point some not insignificant number of people will complain the processes are too onerous, they don't have a local bank, etc.
The problem in my case was that Google changed the rules halfway through. I kept my username and password perfectly secure in my password manager. But one day they suddenly decided that I can't log in until I respond to an SMS code they sent to a phone number they somehow got from me 12 years ago that I no longer have access to. It would be fair for them to not suddenly force SMS MFA without the user's consent.
I lost my yubikey I used for my AWS account (I know, I should have two but I really did not have anything worthwhile on this account). I also changed phone numbers in the meantime as well as email. And then proceeded to forget my root password. I have not used the account for a number of years and it really did not sink in until I needed it.
See? You would think I was totally and utterly fucked.
Well, not. I called them and with a procedure that took some 3 days and numerous phone calls, id photos, etc. But I finally got the access to my account back.
I'm so over the phone system and the credit card system. We have superiors but we are stuck in the past culturally.
If the process takes couple of days and they do a lot of communication, there is a good chance the real owner of the account will get notified and have time to react before the attacker gets access to the account.
Also, the commenters are completely wrong on that it is enough to have the email or ID to get through the process. The AWS people who contacted me required a lot more information that only the owner of the account would know.
And the point of 2FA in the first place is thought by many to prevent social engineering.
All you needed was an id photo and be able to talk on the phone?
That and account history etc. will probably be in many peoples email. Thus access to the email only would allow you to get access to 2FA services too.
Just feels safer to me to have a printed backup of both stored away in case the tech breaks or gets lost.
You just make cloned yubikeys. You can't read data from the key, but you can initialise it with your own data and you can initialise more than one with the same payload.
We're disagreeing over semantics then. I'd call this "being locked out of my account semi-permanently".
I have to say I don't fully understand your perspective. In a sibling comment you admit that free customers ought to be subject to this misery because they are using the service for free, and here you suggest that requiring numerous phone calls and numerous days of non-access to services is not an inconvenience. I suspect we simply have different life priorities. For me, those three days could be critical in my relationships with customers, clients, employers, etc.
Would you like your bank to make it convenient for you to get your money if you forgot your ID? It is double edged sword -- convenient for you is also convenient for somebody who might want to steal your money.
So no, I do not object to AWS doing due diligence when I recover my password because I know this hopefully makes me a bit more secure from somebody else doing the same.
If this doesn't make any sense, it probably is because I have the details quite right, but the end result is I was unable to help him make any more sense of this, and there appears to be literally no way to regain access to his facebook account.
a blessing in disguise perhaps?
One could argue that your accounts were never secured to begin with.
Only culprit that's really enforced it is the Canada Revenue Agency
My bank recently made a 'security' updates and now my Google Voice number no longer works with their text or call 2FA. They provide no other alternatives and I must have it. I have to now call their customer service, wait a half hour to speak to someone, verify my identity, and have them reset in order for me to login.
Thankfully I rarely login to that bank as it's not used for much, but if it goes on for more than 2 months or so - I'll probably switch.
As an aside, open banking is also a joke as it doesn't allow the end user access to their own account, only 3rd parties - simple API access would make this problem moot, as where I hold my funds grants me API access and I can do things like trigger transfers on webhooks etc, very simple and infinitely useful.
A few months later they added TOTP support. Not sure if I influenced that at all, but it's just another reason why I will only ever use a credit union as my main bank.
In practice, a lot of the non-sms factors end up requiring reset every couple of years on average. It means our support orgs end up treating MFA resets as routine and that in itself can lead to situations where you open your customers up to social engineering attacks on support and support tooling.
There's really no easy answer here, my only hope is that eventually we move to government issued, strong, digital identities as second factors.
What if an iPhone user uses Apple Notes to store their TOTP keys (probably one of the most reasonable ways accessible to a non-technical user), but then 5 years down the line switches to Android, 5 more years pass and they've entirely forgotten that they even used to put TOTP codes in Apple Notes 10 years ago, and then they need their TOTP codes?
Securely archiving things which are rarely if ever needed across many decades is an incredibly hard problem, and I would trust approximately 0% of users to do it correctly.
Security is important. Security that is implemented badly costs you business.
I've been a part of designing these types of processes and this is all argued about forever. The alternative is the e*trade approach where I can call in, give my DOB, Address and last 4 digits of my social social and I get a new MFA token immediately. No PIN, no signature nothing.
What company did you say you were designing security policies/processes for...?
The process we use now is automated but customers don't like having to find recovery pins, billing information so a lot of them still call if they get a new phone and their TOTP isn't there. It will also fail for various other reasons related to browser fingerprinting and reputation that I won't go into details about.
MFA recovery is very tricky, most websites don't even let you do it in an automated way for security reasons. If it goes wrong, you've basically broken MFA for your whole site. Banks are the types of places that are going to err way on the side of caution.
Maybe 2FA should be considered a red flag at this point.
There's a complaint link on that page
https://www.fcc.gov/consumers/guides/porting-keeping-your-ph...
Did you ever confirm it arrived at the VOIP service? The last place you can confirm you had access to the number is where you should be looking.
I left the store at end-of-business before the porting was totally complete and the in-store rep couldn't contact the porting team because they'd already gone home. I had data and could receive incoming messages but couldn't make outgoing calls or texts. The in-store rep assured me I could handle this myself the following day. He didn't mention the hours of bullshit I'd endure. I persevered for the same reasons as our Bojangles Aficionado above, but, honestly, I don't know that I saved myself the time that would otherwise have been spent re-authorizing myself on my 2FA accounts.
The gist of the story is that the junky prepaid service didn't give me the right account info from the start, so when it came time to port, Verizon couldn't help me unless I produced account numbers, PINs, and zip-codes. The zip-code was from an address I haven't lived at for 10+ years. (That remains a mystery and is somewhat concerning.) At some point, I was trying to socially engineer the zip-code out of the T-mobile subsidiary rep, which eventually just turned into a plea.
I don't have a magic solution for you, but here are some thoughts about how I'd approach your situation:
* I would recommend continuing to call and escalating as high as you can go. My principle with customer service of major corporations is that if I don't like the response I get, I call back a maximum number of three times. If I get the same response 3x in a row, then that's a hard policy that I'm not going to bypass. Chances are though, whether by human error or a policy designed to be flexible, I will get some leeway.
* Related to the above, in calling back a few times, you might find that the technician you talk to in subsequent attempts is more qualified, experienced, or simply desires to handle your problem efficiently. Essentially, play the game more to win.
* I would also recommend getting T-Mobile and US Mobile on the phone with one another. They have the capacity to do this, and they might discover the problem together as opposed to being able to punt to the other side. Make yourself a nuisance. At the end of the day, you're in the right here.
* Last bit of advice I can impart is make sure you are absolutely speaking to the right team. Most customer service lines are structured in such a way that the first line (FLS) filters out people who don't need specialized help. The problem I faced with Verizon was being asked repeatedly by FLS who staffed the Porting hotline number to do the same troubleshooting steps (e.g. reset network settings on my phone) before speaking to the actual team who handled porting. Verizon might not be structured like T-Mobile or US Mobile, but at some point I was getting detailed information about the status of the Port from a Tech Support rep who ultimately had to hand me off to the Porting team to finalize it.
Good luck!
Who botched the port request? You would have initiated the port request via US Mobile when you signed up for service. They wouldn't depend on T-Mobile "having the number", they would have looked up who had the number and initiated the porting process.
You can see which carrier "owns" your number by going to https://freecarrierlookup.com/.
Now, if you cancelled your service BEFORE you ported the number, then you may be SOL as the number would have been released. Even if not reassigned you may not be able to get the provider/carrier to release it since it is no longer in your name.
I ended up getting one piece of potentially useful advice: after a while, the phone number will possibly get recycled into a generally available pool. IF that happens, and IF I check at the right time, I MAY be able to purchase the number at https://www.numberbarn.com/.
After all that, I just ended up getting a new number. It has now been four months. I check that site a few times a week, no luck yet. I also call the number occasionally, I have a script prepared to try to convince whoever answers to listen to my stupid plea. It's still disconnected.
As for moving forward: just get a new number. You may get the old one back eventually, but don't count on it happening at all, especially not quickly. I had no trouble updating my number for bank accounts. I don't understand why you would be stuck with your old number for a background check service, seems like you should just be able to provide them with a new number.
Maybe that explains why everyone looking at is going "nnnoooope" because the number's owned by someone 3 times removed from existence and those are probably really hard to fix.
I'm curious who the MVNO was, given it clearly wasn't OmniPoint?
The only idea I can think of is to go as far down the *enterprise* rabbithole as possible, if you didn't already try that ( :/ ? ) - in my own experience (with comparatively tiny issues) I've found far less gatekeeping and "wrong number" than the (Interesting™ O.o) phone menus would suggest. Also, one day I also found the enterprise number I'd squirreled away randomly turned into a totally different department (whole new phone menu + tree) but apparently went to the same phones, so don't just try random/wrong phone options, but wrong/unlikely-looking departments' phone numbers too, they might be hubs not spokes. Oh - and calling somewhere Important™ (eg, network operations) at 11:30PM-12AM-1AM might net you a bored, idly curious night person with a bunch of lateral capacity who might not mind the opportunity to do something interesting during their shift lol
https://sec.okta.com/articles/2020/05/sms-two-factor-authent...
The number needs to be recreated at the original provider (assuming no one else has picked it up), activated, ported multiple times (if you have ported earlier) and then brought to the current final provider.
Source - lost a 20+ year old number during a port activity the same way. Fortunately the provider was a client, and got a circle head involved to recover the number in the way it is mentioned above. Took a week.
I have found that my GV number has become useless for most TOTP services, and for a lot of services that want a number to send a text.
I really don’t know, but I do know it’s trending that way for GV, specifically.
My experience is that this is not "increasingly rare" but "almost universal" at this point. VoIP numbers are useless for SMS account verification. People who thought they could bypass phone company price gouging found themselves out in the cold when signing up for email accounts, social media accounts, or even their own bank.
Then look at the LNP history, which is the history of who and when the number was assigned/re-assigned over the years.
Tell both companies that you will be involving the FCC and try to reach the "porting group" who will be able to fix this. Porting problems happen all the time, even with 99% of ports (that might be an optimistic number) happening in a nearly-automatic fashion. (EDIT: I mean the porting group at each company, not the FCC).
https://www.ofcom.org.uk/phones-telecoms-and-internet/inform...
https://www.ofcom.org.uk/phones-telecoms-and-internet/inform...
https://www.telecom-tariffs.co.uk/codelook.htm
If you put in a landline or mobile telephone prefix, it can tell you which network the number was originally allocated to, but it can't tell you if the number has been ported.
"site reached maximum daily limit, contact admin" upon searching.
There are entities that subscribe to the service and fulfill those queries (such as unlec.com or whatever reseller they're getting the information via).
But the Neustar revenue model is to charge per query which is why that site limits the number of queries one can perform.
Every time you place a phone call in US or Canada, the originating carrier does a lookup against the Neustar-NPAC database (also called a "dip") to determine the routing destination for your call.
Only after that response (called a "LRN" or location routing number) is received does call routing truly begin.
1: https://www.npac.com/canadian-number-portability/the-npac-ne...
Is this able to determine if the phone is connected through wifi calling? (There was a discussion yesterday where some one suggested SMS may not be sent to a phone connected to wifi only if the sender did not wish to but I could not see a mechanism that would allow that determination.)
I doubt you can reliably determine if on Wifi or not, although of course the carrier handling that phone would know.
The LIDB data will consist of a field that marks that phone number as a landline, broadband (aka VoIP), cellular, etc.
There are some 2FA implementations you come across will look up whether a number you're trying to enroll is classified as anything other than cellular, and if so, it gets rejected.
1: https://en.wikipedia.org/wiki/Line_information_database
Based on what I've read, some video games are able to determine if you're using a prepaid plan or post paid. I suppose they might just look up the carrier to determine that since it doesn't seem like that level of granularity is available. And the port trick may work there as well.
I also have a Google Voice-backed number (since before Google acquisition, when it was Grand Central), and every now and then I find a site that doesn't accept GV numbers for 2FA. A recent example was Simplisafe.
Does anyone know where "Fraud Risk" and "Textable" come from in unlec's database? My number has fraud risk = high, and textable = No -- even though text works just fine via GV, and it's a personal number with minimal use, so no reason for flag (other than some companies not liking virtual carriers).
My guess is that the port went through but US Mobile has lost it in their system.
One of the biggest issues I see is when porting from a VoIP service to a carrier. The carrier doesn't always know what to do since it is slightly outside normal; the majority of their customers are moving between major carriers. But now your number has been classified as a "wireline" (VoIP) number and US Mobile is probably confused.
Honestly, I bet it magically arrives at US Mobile after a bit of time. But if you can't wait, I'd engage the VoIP service again. They likely operate downstream from a provider such as Bandwidth, Twilio, or similar. Their team can ask their upstream provider for a "snapback" of the number - essentially they can go take it back. That will leave you with your number back at the VoIP service to try again when you're ready :)
With all that said, I do have access to these upstream systems and some more advanced lookup tools. Shoot me an email (in bio) with your number and I can do some research for you if you want. Good luck!
At some point I think AT&T or McLeod even said "What number do you want to lose when you port this?"
I totally expected something to screw up, especially on the Vonage side.