4 ms·
It would take laughably small time to bruteforce the phone number out of a hash. Knowing the algorithm I can compute all possible 10,000,000,000 combinations an
by DenisM 15y ago
It would take laughably small time to bruteforce the phone number out of a hash. Knowing the algorithm I can compute all possible 10,000,000,000 combinations and store them in one file.
Same goes for hashing IPv4 addresses. There is no way to make eitther one secure by hashing.
- feralchimp 15y agoConcatenate FirstName+LastName+emailAddress+phoneNumber, then hash or HMAC that. Your lookup table just got a lot bigger.
- bonzoesc 15y agoAnd the likelihood that you'll match somebody got a lot smaller. Names have different spellings, phone numbers have different spellings (to say nothing of different numbers), people have multiple emails. You can't canonicalize some of these either.
- feralchimp 15y agoSo send multiple hashes per contact! Feral, Chimp, myEmail, myDeskPhone, myCellPhone H1 = sha1(Feral-Chimp-myEmail-myDeskPhone-myCellPhone) H2 = sha1(F-Chimp-myEmail-myDeskPhone-myCellPhone) H3 = sha1(Feral-C-myEmail-myDeskPhone-myCellPhone) H4 = sha1(F-C-myEmail-VALUEOMITTED-VALUEOMITTED) ... ... So flexibility is available, it's just more computationally expensive for the server to do the extra comparisons. The hash calcs use a little extra battery per user, but I'm much happier to donate some of my processor/battery than I am my Address Book contents.
- bonzoesc 15y agoNot all names are simple or even computable transforms though. How do you deal with entries like "Mom" or "Steve," names like "St. Clair" that may be entered dozens of different ways, or non-English names like "姚明" that may have dozens or hundreds of different possible romanizations, anglicizations, francizations, and spellings under any other language? How much extra battery are you willing to spend, and more importantly, how much effort are you willing to spend running your users' batteries down for something that you'd never yourself use?
- deleted 15y ago[deleted]
- feralchimp 15y ago> How do you deal with entries like "Mom" or "Steve," names like "St. Clair" that may be entered dozens of different ways, or non-English names like "姚明" that may have dozens or hundreds of different possible romanizations, anglicizations, francizations, and spellings under any other language? That's sort of beside the point, though. The question is: How does uploading my Address Book information provide a much more efficient or complete solution to that set of problems? I don't think that it does. In each case, you're dependent on heuristics and sometimes those heuristics are going to miss a match. If I were Twitter, I'd happily accept those misses in exchange for hitting the matches where people spell each other's first names and email addresses consistently (for example). > how much effort are you willing to spend running your users' batteries down for something that you'd never yourself use? You lost me there. My point was just that for Twitter, my iPhone CPU/battery are an "externality." So while they might spend more cycles doing server-side comparisons on the hashes my phone sends over, at least they're not paying to compute the hash values.
- josephcooney 15y agoThe engineer in me says you could soundex/metaphone the names before adding them to the hash. The rest of me says apps just shouldn't be doing this.
- phaylon 15y agoI'm probably out of my territory (I don't have a phone right now[1]), but my first UI instinct would be to allow address book entries to be grouped (or tagged or labelled, the actual mechanism is secondary), and on first request from the app being asked what groups I'd like to allow it access to. Bonus points for the option to create a per-app group and put some users in right there and then. But as I said, outside of my territory. [1] I'm not that old, really.
- dcosson 15y agoBut all we care about is making it look secure for the hobbyist packet sniffers, right? (kidding) Although what about hardcoding a salt into the app to hash with?
- quesera 15y agoSalting wouldn't help. The data is collected to match it to other users' data, so the salt would have to be identical for all hashes for all users. An attacker would just precompute the dictionary with the hard coded salt, nullifying its purpose.
- chubs 15y agoYou're right in the case of SHA1. However, with a suitable work factor, you can't bruteforce bcrypt AFAIK
- quesera 15y agoI'm pretty sure the parent meant "precompute" (e.g. a rainbow table), not "brute force".
- chubs 15y agoAgain: you're right in the case of SHA1, but rainbow tables don't apply to bcrypt because of the varying work factor, also you can use a different salt for each person. Crypto is actually really cool these days, there's pretty much a solution to every weakness :)
- SoftwareMaven 15y agoSo your solution to providing a "secure" way to compare phone numbers, etc, between users is to make the hashes non-comparable? Remember, the goal is to make it so two people can come up with the same hash in order to "find" each other.
- harryh 15y ago1) bcrypt uses salts so that won't work at all 2) if you use some other computationally expensive hash you run into the problem of low powered mobile hardware. Remember you're not hashing 1 thing, but dozens or hundreds of phone numbers or email addresses.
- chubs 15y agoYou know, i think you're right - if we use different salts for each emails/phones, there'd be no way of ensuring that different users use the same salts, or even if we stored the salt along with the hash, it wouldn't be much use. Hmm this is a tricky problem!