4 ms·

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

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? ;)
      - axod 18y ago
        1. start backend. Prompt operator for salt, he types it in, it's stored in memory (Yes ok, ok, who knows, maybe the government can go in and ask for a core dump or something, or torture the operator). 2. backend starts, saves hashed IPs someplace to provide some sort of protection against abuse. Starting to wish I hadn't started this ;)
        sho 18y ago
        Ha. That operator better type carefully, because there's no way to check whether he's "right", and any mistake will screw up everything :) Anyway, good, and devious, thinking. Here's an improvement: 1. Start backend. App requests salt over encrypted channel from out-of-jurisdiction web service... whose controller keeps a very close eye on developments at the remote station, including but not limited to a constant ping, camera, and/or motion detectors. 2. as above But man, you're not talking about a hash any more, you're talking about encryption fo' realz. Security at this level has kind of left the arena of salting hashes and has moved on to disk encryption and tamper proofing. You wouldn't be starting the backend and getting the operator to type a salt, you'd be starting the secure DB server and the op would be entering the password to mount the disk. Remotely. I'd love to get into a discussion of what a real secure system looks like, but we're getting a bit off topic .. heh
        axod 18y ago
        "That operator better type carefully, because there's no way to check whether he's "right", and any mistake will screw up everything :)" Why can't the system know the hash of the salt and check that? Getting from the hash of the salt back to the salt would be pretty impossible.
        sho 18y ago
        Lol, you got me there. Yes, OK, if you have an operator standing by 24 hours a day to type in a long secret phrase which will not be stored on disk and will be used as a salt in hashes stored by the system, and will infallibly ensure the server does not fall into the wrong hands in a running state, and there are no other attack vectors, then that is kind of secure. Since your system relies on a secret key, though, you may as well just use encryption in the first place rather than going to these absurd lengths to hammer hash functions into an encryption-shaped hole.

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? ;)
    - axod 18y ago
      1. start backend. Prompt operator for salt, he types it in, it's stored in memory (Yes ok, ok, who knows, maybe the government can go in and ask for a core dump or something, or torture the operator). 2. backend starts, saves hashed IPs someplace to provide some sort of protection against abuse. Starting to wish I hadn't started this ;)
      - sho 18y ago
        Ha. That operator better type carefully, because there's no way to check whether he's "right", and any mistake will screw up everything :) Anyway, good, and devious, thinking. Here's an improvement: 1. Start backend. App requests salt over encrypted channel from out-of-jurisdiction web service... whose controller keeps a very close eye on developments at the remote station, including but not limited to a constant ping, camera, and/or motion detectors. 2. as above But man, you're not talking about a hash any more, you're talking about encryption fo' realz. Security at this level has kind of left the arena of salting hashes and has moved on to disk encryption and tamper proofing. You wouldn't be starting the backend and getting the operator to type a salt, you'd be starting the secure DB server and the op would be entering the password to mount the disk. Remotely. I'd love to get into a discussion of what a real secure system looks like, but we're getting a bit off topic .. heh
        axod 18y ago
        "That operator better type carefully, because there's no way to check whether he's "right", and any mistake will screw up everything :)" Why can't the system know the hash of the salt and check that? Getting from the hash of the salt back to the salt would be pretty impossible.
        sho 18y ago
        Lol, you got me there. Yes, OK, if you have an operator standing by 24 hours a day to type in a long secret phrase which will not be stored on disk and will be used as a salt in hashes stored by the system, and will infallibly ensure the server does not fall into the wrong hands in a running state, and there are no other attack vectors, then that is kind of secure. Since your system relies on a secret key, though, you may as well just use encryption in the first place rather than going to these absurd lengths to hammer hash functions into an encryption-shaped hole.