Or, phrased another way: we are NOT in possession of a phone number any more than we are in possession of an IP address. Both are transiently assigned to us to the computer with a cellular modem in our pockets
Not really. For all intents and purposes you do "own" the number. You can take it to any carrier you want (local number portability), and carriers can't expropriate it. Try doing that with a /32 you got from your ISP, even a static one.
True, but it's important to note phone numbers have the amount of security as e-mail/SMTP for self-identification. That's why it's so easy to spoof phone numbers and how robo-callers work.
Only this year, telecos are finally adding signature verification to caller-ID/reverse lookups. Once every teleco in a given country supports and is required to implement phone number verification, there will be a higher degree of assurance a phone number on your caller ID really is the person calling, but it's not there yet.
The point is you own it in one sense, but the phone company can reassign to someone else (even if temporary, it's still gone). It's not locked to a physical device at your house that no one else can change, it's not like a diamond ring on your finger.
Using phone numbers for throttling user account creation has no security problem. Using phone numbers for 2FA has no security problem compared to password 1FA. The security problem comes when companies use phone numbers for 1FA (during account recovery).
It's an imperfect solution to a difficult problem - throttling user account creation.
A very imperfect solution when it comes to FastMail.
In moving my accounts from Gmail to FastMail it wouldn't allow me to add more than x number of accounts verified with the same cellular number. Even though they were paid accounts. So some of my family remains on Gmail because I only have one phone number that receives SMS messages.
And how many people have those? With appropriate knowledge of how to generate, store, sign, backup, and secure the keys? On the front page of HN at the moment we have "we lost millions of dollars of Oracle DB due to key management issues". Key management is hard. Every few months a crypto exchange discovers this by either leaking or entirely losing their keys.
It's basically just people with Estonian e-identity cards and a handful of people with organisational PKI.
> With appropriate knowledge of how to generate, store, sign, backup, and secure the keys?
I believe this could be solved by improving the interface used to accomplish these tasks (rather than using openssl req directly). Web browsers ask to save passwords and other sensitive information. There's no reason why they cannot relatively securely store a private key and the associated certificates.
> Key management is hard
That is true, but requiring key/certificate based auth in addition to the username and password for authentication means that attacks would have to be distributed amongst the users of a given website and the website itself rather than just attacking the website or some 3rd party used for 2FA (email or cell phone).
And breaches where backend databases are compromised and user credentials are retrieved also happen. But due to people re-using credentials on multiple services, they also get compromised on unrelated services. Using a private key and a certificate per service, it would be much harder to do something like that.
> What if I can't access a trusted device or didn't receive a verification code?
> If you're signing in and don’t have a trusted device handy that can display verification codes, you can have a code sent to your trusted phone number via text message or an automated phone call instead. Click Didn't Get a Code on the sign in screen and choose to send a code to your trusted phone number. You can also get a code directly from Settings on a trusted device.
I thought that by now Apple's engineers had closed the sms loophole. But apparently it is still eminently there.
And this is why customer service representatives and retail sales associates are totally worthless.
Any store front, for any cellular service, is basically populated with the most useless people on earth. You could drone strike every single store that sells smart phones, killing everyone inside of all of them, and the world would be a better place.
When Douglas Adams wrote about launching the most useless members of society into outer space, on Golgafrincham Ark Fleet Ship B, he was talking about these people.
This is the result when companies follow each other. We need to see more innovation in authentication and leadership in best practices. Hijacking of phone numbers is not new and devs need to stop shifting liability to phone carriers when authenticating users to every little thing. Phone carriers have no incentive to secure users data or make the user authentication process more stringent. This results in the consumers being at constant risk, which I feel impacts society as a whole.
The phone carrier has no incentive which is why liability needs to be shifted to them.
The broader telecommunication industry has gotten a free ride long enough. They provide a blatantly insecure and mediocre service, profit from it and tell the world it's not their problem when it fails.
> a form of fraud in which scammers bribe or trick employees at mobile phone stores into seizing control of the target’s phone number and diverting all texts and phone calls to the attacker’s mobile device.
why bother to do that? in australia, you just need to know the person's DOB, address and his mobile account number to get full control of his/her mobile number.
Several sites that I use, even some that support TOTP, still require a phone number.
I hope that since you have to “unlock” your Google Voice number before it can be ported, it’s immune to theft (assuming you protect your GV account of course) and relatively safe to use.
SMS as a second factor is not and is unlikely to be secure for a second factor anytime in the near future given the design of SS7 and the glacial pace that the global telecom industry moves at for upgrading core infrastructure. The lock prevents port-out attacks, but is still not sufficient for considering SMS as okay to use for a second factor. Use TOTP instead.
I use something more secure than SMS as my sole second factor where I can. Unfortunately some sites still require a phone number. I’ve edited my comment to be clear about that.
So if you have to use a phone number, is GV the least bad option?
I think it's better than the phone company, but as discussed, someone could force steal your number. Secondly, if someone hacks your gmail, they can access google voice themselves but just logging in as you.
My freaking gmail is my main barrier against the world. I sure as heck use a yubi key (I have multiple) plus password. If my gmail is hacked, I'd be in trouble like a lot of tech people. I think that's the ultimate - break into gmail and you'd have endless things to steal.
> I hope that since you have to “unlock” your Google Voice number before it can be ported, it’s immune to theft...
I see this sentiment posted here a lot and I'm here to say that it is sadly not a good hope. When you do a number port, the automated/efficient/normal path is that your new provider (the "gaining" provider) submits a request to the number portability authority requesting that your number be moved to its routing away from your old provider (the "losing" provider). The authority passes along the information that the gaining provider submitted and gives it to the losing provider. The losing provider is then responsible for returning an automated "yes," "no," or "wait." If "wait," the losing provider is supposed to reply again within 1 to 7 days indicating actual yes or no; if no reply, then the port will complete with no further action. If yes, then the port will complete. If no, then the port is rejected.
Now, here's the major hole: It is entirely possible to do what's called a "force port," wherein the gaining provider attests to the number portability authority that the gaining provider Really For Sure Totally Does have authorization from you (the subscriber) to take routing for the requested number. This is only supposed to be used in the case of a recalcitrant losing provider or where the losing provider has no automated system and the subscriber wants/needs the number moved Very Fast Now. But, realistically, this very much can be abused and, if an attacker is motivated, will be abused.
There's nothing Google (or, more accurately, its underlying carrier, Bandwidth.com in most cases) can do to stop a force port. All the "unlock" feature on Google Voice does is cause an automated port request to be approved if the other subscriber information matches. If an unlock is not done, then Google Voice will simply return "nope" on all port requests. But a force port can still go around that and, disturbingly, the losing carrier may not even know that a force port was done until days later when it notices that the LRN (local routing number) database no longer points the lost number at its service.
So, SMS is still a terrible idea for verification even on Google Voice numbers.
According to court documents, investigators first learned of the group’s activities in February 2018, when a Michigan woman called police after she overheard her son talking on the phone and pretending to be an AT&T employee.
It's interesting seeing all these novel ways of stealing cryptocurrency. So far we have seen Twitter scams where people impersonate high profile accounts in the hope people will think it's a real cryptocurrency giveaway and actually send funds to various wallets.
Then there is the cryptominer/cryptojacking technique where the unused CPU power of personal computers is used to mine various cryptocurrency (often stealthily run in the background and the user is unaware they are mining cryptocurrency).
Then there was that recent story of the so called 'cryptocurrency bandit' who scraped wallet addresses and then broke into the wallets which were encrypted with a weak password.
If anyone on here knows of other novel techniques (aside from what I mentioned and the SIM-swapping method); then I would love to hear the methods.
People have programs that scan github uploads for AWS, etc credentials accidentally uploaded by victim and spawn images that mind crypto for the attacker’s.
Any attack vector that would otherwise be foiled by a bank is a vulnerability in the case of Bitcoin. It has no consumer protections, like chargebacks or other fraud protections (lost or stolen "cards" or PIN-codes/passwords). There is no automatic or manual review of large transactions built into Bitcoin, which large bank transactions undergo to prevent theft.
Bitcoin has exactly one security measure: that it's mathematically very unlikely that someone will guess or generate the same private key as you (IF you don't use one of the many faulty ways of generating your own key, which are widespread online). From there, the sky is the limit.
You can hack someone's computer or server using whatever vulnerability you wish and steal their private key. You can physically gain access to a computer or simply use violence to demand someone's keys. You can offer a product or service, receive payment, and then simply never deliver the product or a refund. Or someone can seem to pay, you give them a product in return, but the transactions are later unconfirmed after they're long gone.
Some of these things are possible with regular banking, but in nearly all cases funds can be recovered or reimbursed to the account holder.
Bitcoin was not made with these protections in mind whatsoever. And the high-level platforms, even after more than half a decade, have failed to secure themselves or their customers consistently. They are often hacked and resort to going into hiding or creating complex ICOs, IEOs, "haircuts" or other trickery to cover up losses.
How do you trick employees at mobile phone stores into seizing control of a phone number? You give him a fake ID, he checks the ID card's serial number, citizenship number, name, surname, date of birth in the mobile operator's application (which checks it from the governmental API service) or himself from the e-government web site. In this way he understands wheter the ID is real or not and wheter it was stolen or not. If it is real it hands you a new SIM in few minutes. (now it is even harder with ID cards with chips).
If you want to change the owner of the number the employee scans both of your documents and sends it to a governmental bureau and if they approve then the number is transported to the new person. Which it takes at least few days (I think it is intentionally slow).
This one will not save your Google account but it will save your bank account. If you change your SIM card you cannot login to your bank account. You need to recreate a password by calling the bank and answering tons of questions and revalidating your phone number. You might wonder how does a bank knows that a SIM card has been changed. I wonder it too. But the mobile operator probably informs all banks via a API. U have faced this personally 2 or 3 times and my friends have faced it too. So, it is real. (not related but there is also mobile digital signature thing that you can login to bank account, mobile phone operator's web site or your e-government account)
This is how it works in Turkey. I know United Statians don't like 1984 style states but I wanted to share.
40 comments
[ 0.28 ms ] story [ 100 ms ] threadOnly this year, telecos are finally adding signature verification to caller-ID/reverse lookups. Once every teleco in a given country supports and is required to implement phone number verification, there will be a higher degree of assurance a phone number on your caller ID really is the person calling, but it's not there yet.
It's an imperfect solution to a difficult problem - throttling user account creation.
A very imperfect solution when it comes to FastMail.
In moving my accounts from Gmail to FastMail it wouldn't allow me to add more than x number of accounts verified with the same cellular number. Even though they were paid accounts. So some of my family remains on Gmail because I only have one phone number that receives SMS messages.
It's basically just people with Estonian e-identity cards and a handful of people with organisational PKI.
I believe this could be solved by improving the interface used to accomplish these tasks (rather than using openssl req directly). Web browsers ask to save passwords and other sensitive information. There's no reason why they cannot relatively securely store a private key and the associated certificates.
> Key management is hard
That is true, but requiring key/certificate based auth in addition to the username and password for authentication means that attacks would have to be distributed amongst the users of a given website and the website itself rather than just attacking the website or some 3rd party used for 2FA (email or cell phone).
And breaches where backend databases are compromised and user credentials are retrieved also happen. But due to people re-using credentials on multiple services, they also get compromised on unrelated services. Using a private key and a certificate per service, it would be much harder to do something like that.
The big ones have supported this for two decades: https://www.digicert.com/managing-client-certificates.htm
Hardly anywhere uses it.
Sounds like another opportunities for the advertising companies like Google and Facebook to uniquely identify us.
perhaps blockchain can solve this problem too?
Luckily I created my account before it was official policy, but I’m afraid their going to force it on me someday.
And if you turn on 2FA, you only have 2 weeks to turn it off.
> If you're signing in and don’t have a trusted device handy that can display verification codes, you can have a code sent to your trusted phone number via text message or an automated phone call instead. Click Didn't Get a Code on the sign in screen and choose to send a code to your trusted phone number. You can also get a code directly from Settings on a trusted device.
I thought that by now Apple's engineers had closed the sms loophole. But apparently it is still eminently there.
SMS only 2fa should really be discouraged
Any store front, for any cellular service, is basically populated with the most useless people on earth. You could drone strike every single store that sells smart phones, killing everyone inside of all of them, and the world would be a better place.
When Douglas Adams wrote about launching the most useless members of society into outer space, on Golgafrincham Ark Fleet Ship B, he was talking about these people.
The broader telecommunication industry has gotten a free ride long enough. They provide a blatantly insecure and mediocre service, profit from it and tell the world it's not their problem when it fails.
why bother to do that? in australia, you just need to know the person's DOB, address and his mobile account number to get full control of his/her mobile number.
I hope that since you have to “unlock” your Google Voice number before it can be ported, it’s immune to theft (assuming you protect your GV account of course) and relatively safe to use.
https://support.google.com/voice/answer/1065667#xferout
So if you have to use a phone number, is GV the least bad option?
My freaking gmail is my main barrier against the world. I sure as heck use a yubi key (I have multiple) plus password. If my gmail is hacked, I'd be in trouble like a lot of tech people. I think that's the ultimate - break into gmail and you'd have endless things to steal.
I see this sentiment posted here a lot and I'm here to say that it is sadly not a good hope. When you do a number port, the automated/efficient/normal path is that your new provider (the "gaining" provider) submits a request to the number portability authority requesting that your number be moved to its routing away from your old provider (the "losing" provider). The authority passes along the information that the gaining provider submitted and gives it to the losing provider. The losing provider is then responsible for returning an automated "yes," "no," or "wait." If "wait," the losing provider is supposed to reply again within 1 to 7 days indicating actual yes or no; if no reply, then the port will complete with no further action. If yes, then the port will complete. If no, then the port is rejected.
Now, here's the major hole: It is entirely possible to do what's called a "force port," wherein the gaining provider attests to the number portability authority that the gaining provider Really For Sure Totally Does have authorization from you (the subscriber) to take routing for the requested number. This is only supposed to be used in the case of a recalcitrant losing provider or where the losing provider has no automated system and the subscriber wants/needs the number moved Very Fast Now. But, realistically, this very much can be abused and, if an attacker is motivated, will be abused.
There's nothing Google (or, more accurately, its underlying carrier, Bandwidth.com in most cases) can do to stop a force port. All the "unlock" feature on Google Voice does is cause an automated port request to be approved if the other subscriber information matches. If an unlock is not done, then Google Voice will simply return "nope" on all port requests. But a force port can still go around that and, disturbingly, the losing carrier may not even know that a force port was done until days later when it notices that the LRN (local routing number) database no longer points the lost number at its service.
So, SMS is still a terrible idea for verification even on Google Voice numbers.
Then there is the cryptominer/cryptojacking technique where the unused CPU power of personal computers is used to mine various cryptocurrency (often stealthily run in the background and the user is unaware they are mining cryptocurrency).
Then there was that recent story of the so called 'cryptocurrency bandit' who scraped wallet addresses and then broke into the wallets which were encrypted with a weak password.
If anyone on here knows of other novel techniques (aside from what I mentioned and the SIM-swapping method); then I would love to hear the methods.
https://www.theregister.co.uk/2015/01/06/dev_blunder_shows_g...
Bitcoin has exactly one security measure: that it's mathematically very unlikely that someone will guess or generate the same private key as you (IF you don't use one of the many faulty ways of generating your own key, which are widespread online). From there, the sky is the limit.
You can hack someone's computer or server using whatever vulnerability you wish and steal their private key. You can physically gain access to a computer or simply use violence to demand someone's keys. You can offer a product or service, receive payment, and then simply never deliver the product or a refund. Or someone can seem to pay, you give them a product in return, but the transactions are later unconfirmed after they're long gone.
Some of these things are possible with regular banking, but in nearly all cases funds can be recovered or reimbursed to the account holder.
Bitcoin was not made with these protections in mind whatsoever. And the high-level platforms, even after more than half a decade, have failed to secure themselves or their customers consistently. They are often hacked and resort to going into hiding or creating complex ICOs, IEOs, "haircuts" or other trickery to cover up losses.
If you want to change the owner of the number the employee scans both of your documents and sends it to a governmental bureau and if they approve then the number is transported to the new person. Which it takes at least few days (I think it is intentionally slow).
This one will not save your Google account but it will save your bank account. If you change your SIM card you cannot login to your bank account. You need to recreate a password by calling the bank and answering tons of questions and revalidating your phone number. You might wonder how does a bank knows that a SIM card has been changed. I wonder it too. But the mobile operator probably informs all banks via a API. U have faced this personally 2 or 3 times and my friends have faced it too. So, it is real. (not related but there is also mobile digital signature thing that you can login to bank account, mobile phone operator's web site or your e-government account)
This is how it works in Turkey. I know United Statians don't like 1984 style states but I wanted to share.