3 ms·

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 auto

by 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.

by sho 18y ago

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.