Hacker News Reader

Comment by bArray | Hacker News Reader

Mobile phone numbers aren't unique and secure identification of users, stop treating it as such.

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.

Better analogy would be a MAC address instead of an IP address.

They don't have to be totally unique and secure for most users.

It's an imperfect solution to a difficult problem - throttling user account creation.

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.

Also true of social security numbers, especially with the credit bureau hack.

And even if they were, SMS is not a secure communications medium.

This is why I hate Apple’s new policy of requiring 2FA with a mobile number for new accounts.

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.

> 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.

It's fine to require 2fa as long as using an app instead of SMS is allowed.

SMS only 2fa should really be discouraged

What is, though?

A private key with an associated public key signed by one or more entitities that have verified the owner of the private key.

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.

> There's no reason why they cannot relatively securely store a private key and the associated certificates.

The big ones have supported this for two decades: https://www.digicert.com/managing-client-certificates.htm

Hardly anywhere uses it.

signed by one or more entitities

Sounds like another opportunities for the advertising companies like Google and Facebook to uniquely identify us.

There are blind signature schemes.

as the guy before me mentioned private key and public key

perhaps blockchain can solve this problem too?

Too? What other problems has blockchain solved?

Reply on news.ycombinator.com