4 ms·

Of course, it's not a technical problem. They could keep a hash instead of a copy. But I'm sure people who find the 'hidden tool' and request to have their info

Of course, it's not a technical problem. They could keep a hash instead of a copy. But I'm sure people who find the 'hidden tool' and request to have their information removed are interested in specific products, so a list of these people is very valuable to train machine learning models on..

m463 4y ago
I wonder what happens if someone blocks their phone number, then switches it. Will the re-used number be blacklisted forever with a hash scheme?
- robertlagrant 4y ago
  That's my thought as well. Maybe they should just stop using phone numbers for discovery purposes.
kadoban 4y ago
Hashes of phone numbers is unfortunately not actually useful in almost any circumstance. You can trivially reverse them by iterating through every phone number and computing the hash. Hashes of emails is not quite as useless, but not far off (consider 90+% of emails are at like ~3 domains, and also that lists of vaguely ~valid email addresses aren't hard to get).
- popcalc 4y ago
  This is the same reason hashing a SSN is purely security through obscurity. Anyone with a couple GB of space to spare for a text file can easily perform a reverse lookup. https://gist.github.com/stouset/4322307 https://gist.github.com/stouset/4322307
  - lotsofpulp 4y ago
    This is why any business that uses SSN as authentication should be liable for any losses that result from fraudulent usage of the SSN, as opposed to the SSN’s owner being liable.
- addingadimensio 4y ago
  Hash and salt
  - galeaspablo 4y ago
    How could I match an incoming unhashed value to an existing salted hash?
    - m4jor 4y ago
      hashcat
  - ohbtvz 4y ago
    There are only about 3 billion valid US phone numbers. How many hashes can your GPU compute per second?
    - m4jor 4y ago
      Most people crack with multiple GPUs. For example, I have a 5 GPU (3080s) rig that I used for mining ETH but now can use to crack with hashcat. tl;dr crack fast af boiii.
    - parker_mountain 4y ago
      Back of the hand math, and some benchmarking, suggests that a consumer laptop GPU from about 2015 could bang it out in a month. And, that's being (extremely) pessimistic. (Assuming a GPU takes .001s to do a sha3 hash, which is more than double the actual benchmarks). I would estimate that a single, high end GPU from the last or current generation could probably chew through it in under a week.
    - DenisM 4y ago
      One can easily devise a hash function that a GPU can only compute once per second. Or per year, even, although that would be impractical.
  - kadoban 4y ago
    If you salt, then either you can't lookup a number, or you've only changed the problem to: iterate over all the possible phone numbers, _add the salt_ and hash them. No big difference.
- qxmat 4y ago
  Slow hash function + salt would solve this.. e.g. you'd be lucky to do more than 10 hashes a minute with bcrypt and 20 salt rounds.
  - m4jor 4y ago
    Yeah but with hashcat supporting cracking with multiple GPUs, even bcrypts can be cracked quickly now. There are also a ton of cloud cracking services like GPUHash.me and entire cracking forums where ppl crowdsource and help out like HashKiller.
  - kadoban 4y ago
    You can try that, but it's really difficult to tune so it's useful. The amount of time the server has to waste computing hashes is too close to the amount of time an attacker has to waste to break at least some of them. It's just not hard enough to guess a potentially valid phone number. With passwords, hashing only helps because the probability of a valid password is _very_ low, and because you don't need to look up a password, only check if it's the right one for joeblow (so you can salt them individually).
- gerdesj 4y ago
  "You can trivially reverse them by iterating through every phone number and computing the hash." Well yes and no. What exactly is your understanding of a phone number 8) Not everyone is blessed with the NANP. I'm a Brit and we have an eye wateringly complicated nonsense of a numbering plan and our's isn't the worst. What do you hash? Perhaps the standardised international representation or one of them (no that is not a joke - telephony is weird). For a laugh you could try one of the many colloquialisms. For example a UK number might be 00441395112233 or 441395112233 or +44 (0)1395 112233 - the final part might be displayed as 112 233 or 112-233. Imagine if the database works by operating on all numbers in locally correct colloquial mode and hashes that! Now let's really get silly: There are hashes that are nasty to compute but easy to check and vv. We'll use whatever is indicated. Anyway this is all a very well researched problem, there is no need for silly games: passwords.
  - ajsnigrutin 4y ago
    This data is normalized before it's even saved to the database. You cannot send an sms to "+44 (0)1395 112-233", so they remove the stuff in parenthesis, the dashes, spaces, etc. first, and then store.
  - kadoban 4y ago
    Phone numbers get complicated, yeah, but US numbers are pretty trivial (and so are they in several other places, and even for UK it's just more annoying, not really computationally harder). So at _best_ the security analysis is: "okay, all US phone numbers and a bunch from other places might as well be in cleartext", which is already broken enough that it's basically useless.
  - groffee 4y ago
    So normalise the data first? Your comment literally makes no sense at all.

m463 4y ago

I wonder what happens if someone blocks their phone number, then switches it. Will the re-used number be blacklisted forever with a hash scheme?

robertlagrant 4y ago
That's my thought as well. Maybe they should just stop using phone numbers for discovery purposes.

kadoban 4y ago

Hashes of phone numbers is unfortunately not actually useful in almost any circumstance. You can trivially reverse them by iterating through every phone number and computing the hash. Hashes of emails is not quite as useless, but not far off (consider 90+% of emails are at like ~3 domains, and also that lists of vaguely ~valid email addresses aren't hard to get).

popcalc 4y ago
This is the same reason hashing a SSN is purely security through obscurity. Anyone with a couple GB of space to spare for a text file can easily perform a reverse lookup. https://gist.github.com/stouset/4322307 https://gist.github.com/stouset/4322307
- lotsofpulp 4y ago
  This is why any business that uses SSN as authentication should be liable for any losses that result from fraudulent usage of the SSN, as opposed to the SSN’s owner being liable.
addingadimensio 4y ago
Hash and salt
- galeaspablo 4y ago
  How could I match an incoming unhashed value to an existing salted hash?
  - m4jor 4y ago
    hashcat
- ohbtvz 4y ago
  There are only about 3 billion valid US phone numbers. How many hashes can your GPU compute per second?
  - m4jor 4y ago
    Most people crack with multiple GPUs. For example, I have a 5 GPU (3080s) rig that I used for mining ETH but now can use to crack with hashcat. tl;dr crack fast af boiii.
  - parker_mountain 4y ago
    Back of the hand math, and some benchmarking, suggests that a consumer laptop GPU from about 2015 could bang it out in a month. And, that's being (extremely) pessimistic. (Assuming a GPU takes .001s to do a sha3 hash, which is more than double the actual benchmarks). I would estimate that a single, high end GPU from the last or current generation could probably chew through it in under a week.
  - DenisM 4y ago
    One can easily devise a hash function that a GPU can only compute once per second. Or per year, even, although that would be impractical.
- kadoban 4y ago
  If you salt, then either you can't lookup a number, or you've only changed the problem to: iterate over all the possible phone numbers, _add the salt_ and hash them. No big difference.
qxmat 4y ago
Slow hash function + salt would solve this.. e.g. you'd be lucky to do more than 10 hashes a minute with bcrypt and 20 salt rounds.
- m4jor 4y ago
  Yeah but with hashcat supporting cracking with multiple GPUs, even bcrypts can be cracked quickly now. There are also a ton of cloud cracking services like GPUHash.me and entire cracking forums where ppl crowdsource and help out like HashKiller.
- kadoban 4y ago
  You can try that, but it's really difficult to tune so it's useful. The amount of time the server has to waste computing hashes is too close to the amount of time an attacker has to waste to break at least some of them. It's just not hard enough to guess a potentially valid phone number. With passwords, hashing only helps because the probability of a valid password is _very_ low, and because you don't need to look up a password, only check if it's the right one for joeblow (so you can salt them individually).
gerdesj 4y ago
"You can trivially reverse them by iterating through every phone number and computing the hash." Well yes and no. What exactly is your understanding of a phone number 8) Not everyone is blessed with the NANP. I'm a Brit and we have an eye wateringly complicated nonsense of a numbering plan and our's isn't the worst. What do you hash? Perhaps the standardised international representation or one of them (no that is not a joke - telephony is weird). For a laugh you could try one of the many colloquialisms. For example a UK number might be 00441395112233 or 441395112233 or +44 (0)1395 112233 - the final part might be displayed as 112 233 or 112-233. Imagine if the database works by operating on all numbers in locally correct colloquial mode and hashes that! Now let's really get silly: There are hashes that are nasty to compute but easy to check and vv. We'll use whatever is indicated. Anyway this is all a very well researched problem, there is no need for silly games: passwords.
- ajsnigrutin 4y ago
  This data is normalized before it's even saved to the database. You cannot send an sms to "+44 (0)1395 112-233", so they remove the stuff in parenthesis, the dashes, spaces, etc. first, and then store.
- kadoban 4y ago
  Phone numbers get complicated, yeah, but US numbers are pretty trivial (and so are they in several other places, and even for UK it's just more annoying, not really computationally harder). So at _best_ the security analysis is: "okay, all US phone numbers and a bunch from other places might as well be in cleartext", which is already broken enough that it's basically useless.
- groffee 4y ago
  So normalise the data first? Your comment literally makes no sense at all.