Hacker News Reader

Comment by evan_ | Hacker News Reader

You could turn the verification around. Instead of texting a value to a phone number and asking you to toe it in, you say “Text this number to 40404: 123456”

Then, wait until someone texts that number in, and salt/hash the caller ID number and compare it to what you’ve got stored. If there’s a match, then you’re authenticated.

Probably lots of issues with this from ux perspective…

View on HN

I think the main problem is that SMS sender numbers can be easily spoofed (might depend on country, operator, …), so relying on “this message came from where it says it came from” is not really possible.

It might not be an issue for some types of usage, but sounds risky if used for account security/recovery/etc.

If you keep your number private it won’t matter. In fact you could spoof the number on purpose for an extra layer of security.

Phone number verification (of any kind) is supposed to make sure that the phone number provided belongs to the account owner.

If the number is not actually validated in a secure (enough) manner, there's no point in using phone numbers at all.

Why not just have the user enter their phone number? You only store a hash of it and only verify whether it is indeed the one they registered with, and use the real one only for the duration of sending an SMS.

Not too secure, as phone numbers are easy to crack (possibly with randomized salt, that even twitter has to “brute force”?), but at least not every entry will be easily readable.

SMS shortcodes aren't international.

You could give the user a list of phone numbers sorted by country.

It's not 2FA if a secret comes from the same channel as the login one.

Reply on news.ycombinator.com