6 ms·

"The technical need to store IP addresses for 48 hours – blocking automated use of Ixquick's servers – has been overcome by recent technological developments,"

• sho 18y ago
  Huh? Hashing an IP address protects anonymity? Against who? You do realise an IP address is 4 bytes? You could brute force guess the thing in a few minutes, and generate a rainbow table for the whole possible set in an hour or two, much less if you had a lot of memory. It's no protection whatsoever.
  • axod 18y ago
    Surely that would require you to know the hash and the IP :/ If you only have a hash, how can you brute force it? How do you know when you got back to the correct IP? If a system is only spewing out a stream of hashed IPs, it doesn't seem too easy a problem to deduce the original IPs.
    • sho 18y ago
      It depends on who you're trying to protect against. I immediately assumed the government trying to find out who searched for $STRING, implying they have full access to everything else as well. Seeing that you have the hashed IPs, I assumed you have access to the database and probably physical access to the machine. In that case you would just look at the code, or subpoena a programmer, for the hashing algorithm. It wouldn't be anywhere near as easy if you were dealing with some custom algorithm, especially if it were salted, but I can't really think of a situation where you'd have the records but not the rest. Why would hackers be trying to find out which IP searched for what? It's a government thing, surely.
      • axod 18y ago
        Oh sure point taken, if you have the hashes and the hashing algorithm, as you say - it's only a 4 byte input, wouldn't be too hard. You could make the hashing algorithm change over time, which would make things a little harder to reverse. Perhaps my original comment was a little knee jerk, just seems like a problem that has been solved.
        • sho 18y ago
          Solved problem? Sorry to harp on about this but I'll go all out and say it's an _unsolvable_ problem. If you store IP addresses, in any form whatsoever, and you have a process that can take an IP and consistently convert it to the form in your store for lookup - without which, of course, there is no point storing them at all - then because of the small possible set of IPv4 addresses, that system can be quickly and easily brute-forced and the records recovered in full. The only way to store IP addresses such that they cannot be recovered with sufficient leverage (ie, govt) is to not store them at all. Even storing them in memory is not safe - just ask TorrentSpy. The article is light on details but I have a strong suspicion that the ground-breaking "technological development" they are referring to is otherwise known as the "cookie".
          • axod 18y ago
            Well. Storing anything securely depends on some 'secret' information. If you're assuming the 'secret' information can be made public, then of course, it's an unsolvable problem - you can never store anything securely.
            • sho 18y ago
              I think we're talking about different things : ) When I consider a search engine obscuring the IP addresses for its search records, I assume the "enemy" is the government. It's governments who want to know who's been searching for child porn and bomb-making instructions. They want the IPs, and they can get the algorithm. Now if you're talking about someone with less resources, who can get the obfuscated records but not everything else, your arguments make perfect sense, but I can't imagine who'd be interested other than governments.
    • matthavener 18y ago
      I think he's saying that if you know the hash function, building a reverse lookup table for every IP address is feasible... just look at all the web accessible reverse md5 tables
      • axod 18y ago
        Sure :) I wasn't imagining anyone would md5/sha1 without salt etc
        • sho 18y ago
          All the salt means is that you can't use a so-called rainbow table. Assuming the salt is known, and it must be for the system itself to be able to look up its own records, you can simply recreate the salted string and start from the beginning with that. There are 4 billion possible combinations. A single nVidia 9800GX2 can try 608 million of those* per second. You do the math. Sorry to pick on you mate : ) * md5, http://www.elcomsoft.com/lhc.html http://www.elcomsoft.com/lhc.html
          • axod 18y ago
            "Assuming the salt is known" Look. For the last time. I'm assuming there is some secret information that is not known. I shall stop posting to this thread because that bit doesn't seem to be getting across well :)
            • sho 18y ago
              That is your prerogative of course, but your understanding of what a salt is is flawed. It is not an encryption key. It is a layer of defence to frustrate automated attacks, and is almost always stored right next to the hash in the same table. In security design, it is assumed that if the hash is known, the salt is also known. I am kind of scratching my head trying to imagine what kind of setup you are envisaging. If the salt isn't stored in the DB, where is it stored?! Maybe a sysadmin, manually entering the secret password from memory on every request? ;)
• DenisM 18y ago
  please stay away from designing anything related to securty. or at least point your users to this thread. thanks.
  • axod 18y ago
    What an excellent counter-argument you pose. Well done. I guess I should have also put: Don't use a standard hashing algorithm without salt In addition, make the salt secret - type it in when the program starts. Or as sho suggests transmit it from an out of jurisdiction site over a secure channel. To be honest I assumed those points would be obvious. We're on Hacker news, not Digg.
    • DenisM 18y ago
      I didn't mean to insult you, my suggestion was sincere. Secure design is not something that can be relayed via small forum messages, the best I can do is plead for you to not implement those schemes but instead take more fundamental approach of either taking time to learn this subject in depth or leaving it to someone who has.
      • axod 18y ago
        ok, thanks ;) . I have learnt a reasonable amount about the subject.. I'm still pretty confident that if all you possess is some hashes, with no knowledge of the hashing algorithm, salt etc, you won't be able to work out any of the IPs. If you think that assertion is false, please educate and explain why. But as you say, forums leave way too much room for misinterpretation in the finer details...
        • DenisM 18y ago
          Your design may be secure software design but it is not a secure system design. When a system consists of multiple components you need to take into account the security and the failure modes of each individual component as well interactions between those failures. The operator does not need to be tortured, he simply needs to be told to cough up the salt or get tried on terrorism charges in a secret court. How many people will you find willing to trade their freedom for your corporate profits? More importantly, you don't know whether they will or will not fold, regardless of what they tell you at the job interview. Next, if the operator is the only one to know the secret, what is to stop him from blackmailing your businesses? Or dying under the bus and taking the secret with him? You will have to introduce a backup person who also knows the secret and is also fallible in the same way, increasing your risk. The questions of loyalty and conflicting interests are collectively known as "the agency problem" - where agents act not consistent with the interests of their employers. Given agency problems soon enough you will come to a point where someone with big stake in the company (like a founder or CEO) has to know the secret to avoid possible conflict of interest. Of course such person will also have a lot to lose and will be even more likely to fold under simple pressure such as arrest of their assets. The idea with storing the salt out of jurisdiction also has weak spots in it: first, you can't use public CA because NSA likely has their own certs signed by all major CAs. You would need to roll your own SSL cert and deliver it physically. Next, there wouldn't be any machine-gun-toting people streaming into the datacenter - there will be a subpoena to the CEO and if he does not comply he will go to jail and lose his mansion. Is it possible to set data such that CEO can not fetch the data? Technically yes, but realistically CEO that does not control his secrets will likely feel uneasy about losing those secrets to an accident or an agency problem and so he will most likely try to assert control over said secret. At which point he becomes a point of attack. Now, how does remote site know not to dispense secrets to a anyone who asks? It would have to ask requester for an ID and that ID will be stored on the (now confiscated) machine. Then, who will administer the remote site? What are his legal and moral obligations? Can their government compel them to cough up the secrets on request of your government? Further, RAM can and does get examined. There are consumer-level tricks with canned air that allow to reboot the machine while keeping RAM content intact for the next booted OS to chew on. This was at the heart of the recent TPM security breach (for some implementations of TPM). Also when machines are being confiscated they are not unplugged, there are products that allow to transport machine without losing power. The system is complex and there will likely be bugs at the points where some components talk to some other components.