2

I understand that using a salt makes it harder to find cleartext using rainbow tables - but in that scenario the clear text is structured / low entropy. If my clear text is generated randomly, then is there any benefit to using a salt?

The problem I am trying to solve is that of encrypting http session data serverside. I don't want to persist the decryption key on the server, hence currently I am storing separate cookies for the session identifier and the encryption key at the client. But it occurred to me that if I just stored a single value (the decryption key) at the client, then use the hash of that key as the session identifier, then (in principle) the key cannot be derived from the information stored at the server.

  • you are right about the salt's use, but an abundance of caution rarely hurts. – dandavis Jun 25 at 20:56
  • It sounds a bit like you’re rolling your own encryption / cryptosystem. Is there not already a mature solution you could use rather than coming up with your own method? Asking for advice about how to design/implement crypto almost always means you should be using something that already exists and has been properly vetted. Sorry, this is not an answer to your question but it sounds like this is development of production application and not a hypothetical curiousity. – adam Jul 28 at 15:35
  • "Is there not already a mature solution...." - not that I could find - but I did explain the problem this is intended to solve. If you have a suggestion, I would be very interested to hear about it. – symcbean Jul 28 at 21:31
2

Assuming the encryption keys will never be duplicated across multiple users - which I should hope won't happen - then salting is not required for your specific attack scenario.


With that said, the scenario you describe has the users sending the decryption key to the server with every request they make. If the data must be stored server-side and you only care about it being encrypted at rest, that works - somebody who does something like steal a backup of all the session data won't be able to decrypt it - but it's fragile. An attacker who gets access to the running server or to a user's network traffic would be able to steal the decryption keys and use them. I don't know enough about your use case to design a system that would definitely work better, but it's worth considering whether it's acceptable to you that your user's data is trivially decryptable as far as the server process is concerned.

  • Nothings perfect - this avoids using a static, persistent key on the server (how suhosin does session data encryption) and avoids writing the key to the filesystem (but I get that RAM=storage on a lot of systems) – symcbean Jun 26 at 20:15
  • Sure. End-to-end security (only the client can generate/decrypt the key that secures all their data, and the client performs all of the crypto itself and never lets the server see the key, at least not in plain text) is better, but also a lot more complicated. It also sort of barely matters for a web app; since the browser can load the client-side code (JavaScript) from the server on every page load, a malicious actor could modify the script to send the key to the server/attacker anyhow. – CBHacking Jun 26 at 21:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.