Do note that phone numbers are the worst form of 2-factor security, and should be avoided whenever possible. Sim swapping attacks are very easy to pull off and not just restricted to...
Do note that phone numbers are the worst form of 2-factor security, and should be avoided whenever possible.
Sim swapping attacks are very easy to pull off and not just restricted to "high-profile" people.
It’s a good idea. May as well add a salt to them before hashing as well. My phone number was leaked ages ago from sites not doing this and getting breached. edit: the main issue that it’s fairly...
It’s a good idea. May as well add a salt to them before hashing as well. My phone number was leaked ages ago from sites not doing this and getting breached.
edit: the main issue that it’s fairly weak protection in the end, just because the input space is so low. There’s like ballpark 4 billion or so legit phone numbers in the US, and a 3080 could brute force all 4 billion in less than 5 minutes. A more expensive hash would help but in the end there’s just not enough phone numbers.
You're absolutely right, but if I'm reading this correctly it's so much less that you can do it in about 0.75 seconds. Which makes no real difference to the conversation at hand, it just blows my...
a 3080 could brute force all 4 billion in less than 5 minutes
You're absolutely right, but if I'm reading this correctly it's so much less that you can do it in about 0.75 seconds. Which makes no real difference to the conversation at hand, it just blows my mind how fast these things actually are - a friend pointed something similar out to me recently, which is what prompted me to double check.
Yeah I gave it some leeway since you could pick hash algorithms that are slower but for most mainstream hashes you can burn through them at an insane rate on modern gpus. Fun fact: even if you...
Yeah I gave it some leeway since you could pick hash algorithms that are slower but for most mainstream hashes you can burn through them at an insane rate on modern gpus.
Fun fact: even if you just ignore the actual rules for phone numbers and just brute force all 10^10 possible numbers that could be phone numbers it would only take just over a minute if they’re sha256 hashed.
I would suspect that there are simply few enough valid phone numbers that no possible hash algorithm could be both slow enough to resist brute forcing and fast enough to be useable at a reasonable...
I would suspect that there are simply few enough valid phone numbers that no possible hash algorithm could be both slow enough to resist brute forcing and fast enough to be useable at a reasonable scale.
Yup, will need a slower hash function and also salting, However, If the whole server is breached, so will the salt, I thought about user choosing salt, but then they will have to remember it and...
Yup, will need a slower hash function and also salting, However, If the whole server is breached, so will the salt, I thought about user choosing salt, but then they will have to remember it and shouldn't forget it, thus, making it unusable, wish phone numbers were longer.
The main point of the salt is to prevent rainbow table attacks (ie someone could precompute all the sha256/bcrypt/etc hashes for the database of phone numbers mine is apparently in) Although,...
The main point of the salt is to prevent rainbow table attacks (ie someone could precompute all the sha256/bcrypt/etc hashes for the database of phone numbers mine is apparently in)
Although, thinking more on it, probably won’t matter that much given how easy it would be to brute force.
First: The myriad incorrect uses of capitalization and punctuation riddling the article were extremely distracting for me. If this were some kind of psychological experiment, to test how many...
First: The myriad incorrect uses of capitalization and punctuation riddling the article were extremely distracting for me. If this were some kind of psychological experiment, to test how many people found it jarring, well, I think it totally succeeded doing just that.
Second: (unless I've misunderstood the proposal) This isn't how 2FA works. If all we're asking services to do is check a computed hash (in the present) against a stored hash (acquired in the past), then that is essentially just a password. There wouldn't be any mechanism whereby ownership of the phone is confirmed. That's what standard 2FA is: two-factor. One: something you know (password), and, two: something you have (such as a phone with a uniquely-configured app, or usb dongle). The proposal boils it down to just the "know" part; two passwords.
Third: to hedge against the original issue (third party acquiring your precious legit phone number), you have to avoid actually giving it. As such, the hashing needs to be done client-side, such as by a local app on the computer or mobile device. And then only the hash should be transmitted to the third party. Sending the unhashed phone number to the third party to have it do the hashing defeats the original purpose.
I see. I think it would help for the article to be reworded to emphasize that this is a benefit from the perspective of the service provider, not per se the end user. It gives the provider perhaps...
I see. I think it would help for the article to be reworded to emphasize that this is a benefit from the perspective of the service provider, not per se the end user. It gives the provider perhaps some deniability, and also protects the phone numbers in the event of a provider-side breach. To be clear: It doesn't help the end user hide their phone number from an untrusted provider.
It doesn't use Phone number as password, It should have been more clear, it means that it will verify the computed hash and if correct, send OTP and continue the usual 2FA procedure, so, even if...
It doesn't use Phone number as password, It should have been more clear, it means that it will verify the computed hash and if correct, send OTP and continue the usual 2FA procedure, so, even if it doesn't add security, it won't reduce as well as we are already storing plain text phone number. A hacker who breaches will have to put some effort brute forcing each phone number, which is ofcourse possible.
Do note that phone numbers are the worst form of 2-factor security, and should be avoided whenever possible.
Sim swapping attacks are very easy to pull off and not just restricted to "high-profile" people.
It’s a good idea. May as well add a salt to them before hashing as well. My phone number was leaked ages ago from sites not doing this and getting breached.
edit: the main issue that it’s fairly weak protection in the end, just because the input space is so low. There’s like ballpark 4 billion or so legit phone numbers in the US, and a 3080 could brute force all 4 billion in less than 5 minutes. A more expensive hash would help but in the end there’s just not enough phone numbers.
Better than nothing, though.
You're absolutely right, but if I'm reading this correctly it's so much less that you can do it in about 0.75 seconds. Which makes no real difference to the conversation at hand, it just blows my mind how fast these things actually are - a friend pointed something similar out to me recently, which is what prompted me to double check.
Yeah I gave it some leeway since you could pick hash algorithms that are slower but for most mainstream hashes you can burn through them at an insane rate on modern gpus.
Fun fact: even if you just ignore the actual rules for phone numbers and just brute force all 10^10 possible numbers that could be phone numbers it would only take just over a minute if they’re sha256 hashed.
I would suspect that there are simply few enough valid phone numbers that no possible hash algorithm could be both slow enough to resist brute forcing and fast enough to be useable at a reasonable scale.
Yup, will need a slower hash function and also salting, However, If the whole server is breached, so will the salt, I thought about user choosing salt, but then they will have to remember it and shouldn't forget it, thus, making it unusable, wish phone numbers were longer.
The main point of the salt is to prevent rainbow table attacks (ie someone could precompute all the sha256/bcrypt/etc hashes for the database of phone numbers mine is apparently in)
Although, thinking more on it, probably won’t matter that much given how easy it would be to brute force.
First: The myriad incorrect uses of capitalization and punctuation riddling the article were extremely distracting for me. If this were some kind of psychological experiment, to test how many people found it jarring, well, I think it totally succeeded doing just that.
Second: (unless I've misunderstood the proposal) This isn't how 2FA works. If all we're asking services to do is check a computed hash (in the present) against a stored hash (acquired in the past), then that is essentially just a password. There wouldn't be any mechanism whereby ownership of the phone is confirmed. That's what standard 2FA is: two-factor. One: something you know (password), and, two: something you have (such as a phone with a uniquely-configured app, or usb dongle). The proposal boils it down to just the "know" part; two passwords.
Third: to hedge against the original issue (third party acquiring your precious legit phone number), you have to avoid actually giving it. As such, the hashing needs to be done client-side, such as by a local app on the computer or mobile device. And then only the hash should be transmitted to the third party. Sending the unhashed phone number to the third party to have it do the hashing defeats the original purpose.
I see. I think it would help for the article to be reworded to emphasize that this is a benefit from the perspective of the service provider, not per se the end user. It gives the provider perhaps some deniability, and also protects the phone numbers in the event of a provider-side breach. To be clear: It doesn't help the end user hide their phone number from an untrusted provider.
It doesn't use Phone number as password, It should have been more clear, it means that it will verify the computed hash and if correct, send OTP and continue the usual 2FA procedure, so, even if it doesn't add security, it won't reduce as well as we are already storing plain text phone number. A hacker who breaches will have to put some effort brute forcing each phone number, which is ofcourse possible.