I'm primarily an ASP.NET developer but this question really applies regardless of language. So obviously it is a good idea to prevent external attacks that arise from session hijacking and csrf attacks as well. But what about internal attacks when the data involved is temporary, needed for the entire session but also sensitive and worth stealing? There is the naturally just only hire trustworthy people route, but lets say that doesn't apply.

Say it is a given you already have code reviews and strict production data access permissions to prevent theft by developers. The application encrypts sensitive data before storing to prevent theft by dbas.

How do you protect your temporary sensitive data against web server admins? It seems that they could retrieve information by inspecting web server logs, traffic sniffing and inspection of process memory contents. Naturally I would say production web server admins do not have access to the raw source code.

  • Out of curiosity - What leads you to believe that your temporary data (as currently persisted) is insecure? Your answer might lead to a specific, targeted solution. – Jim G. Jul 28 '12 at 18:32
  • @JimG. My application runs for many organizations and has a database for each one. Each organization has an organization supplied password which is used as an encryption key and as the password for its database connection. The password is never permanently stored (except for the DB user). This password is currently stored in the user's session for ease of access and avoid prompting the user for the password on every submission. – Peter Smith Jul 28 '12 at 18:36
  • Wow. That seems complicated. When you say "many", how "many" do you mean? And why did you decide to wall the data off into separate databases? // And the password is stored in the user's session? Do you mean the user's password or the database password? – Jim G. Jul 28 '12 at 18:43
  • Use a test/fake data which is close to the real one in your Testing and Development and UAT environments. – Yusubov Jul 28 '12 at 18:47
  • @JimG. Many as in currently unbounded. Organizations are created through the web app. // Data walled off to prevent one organization from accessing another organization's data via some sort of injection\attack. // Password in session is organization password, so that the connection to the database can be made. User passwords are handled in separate database via membership provider. // Separate database accounts and databases to ensure limitation of privileges. – Peter Smith Jul 28 '12 at 18:52

If you cannot trust your own sysadmins with your servers, almost all is lost. The only way to protect sensitive data from somebody with root / administrator access to a production machine is to encrypt it against a key inaccessible to the sysadmin; for example, if the data is only ever used on the client, you could consider client-side encryption. But even then, there is nothing stopping a rogue sysadmin from just changing the server-side code that causes client-side encryption to, well, not encrypt anymore, or use a compromised encryption key. You gain little, but you sacrifice a lot of convenience and performance.

That doesn't mean you shouldn't consider temporary data from a security point of view: often, there are many users with nonprivileged access to a server; even if those can't log in directly (e.g. service accounts), an attacker who exploits other vulnerabilities may very well gain a shell with such a user. Naive use of memcache is easily exploited - you just need to connect to memcache locally, find the key you're interested in, and read the data. Tempfiles are slightly harder to get to, but certainly not impossible.

As with all things security: define your threats, find possible mitigations, and make a cost/benefit analysis.


Best thing you can do is limiting who has access to what. People with access to production boxes should not have access to the code. People with access to the code should not have access to production boxes (of course there will be temporary exceptions to those, like the need to investigate a bug occurring only on production boxes) Like you said, a sysadmin could always sniff the network, or even put your app inside a emulator, and logging all the relevant accesses to memory. There's just nothing you can do about it.

All the recent data leaks we've seen came from people with authorized access to the data (most of wikileak sources), poorly implemented password storage (steam, Sony...) or from 0day exploits. Encrypting your memory won't help you in any of those cases, which your are more likely than not vulnerable to.


In my experience once a web application goes live then the web admins are responsible for it. Data should not be hidden from sys admins just in case emergency action needs to be undertaken to rectify a bug. At best you can obfusicate and encrypt data but that does not gurantee security. The only secure web server is one that is disconected from the internet and locked away in a safe.

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.