1

For a webapp which stores encrypted files, a public key is used to encrypt random key/ivs, which are used to encrypt the stored files. The private key, used for decryption, is guarded with a password that must be supplied by the user to access the files (the nature of the system is such that only one user has/needs the ability to access the files unencrypted).

In order to prevent the user from needing to type the private key password on every page load, it should be stored (say, for 10 minutes). The question is, where/how to store it?

  • Putting it in a cookie is analogous to the user typing it on every request, so that's an advantage. But, then someone with access to their computer could look at their browser's data and see/retrieve the key in plain text. Plus it's up to the browser to expire it on time (which it could choose not to do)

  • On the other hand, it could be stored in session data on the server. This gives better control over its expiration, and means the key isn't flying all over the internet with every request (obviously, this is all over https, but still). But that means storing the password, the key, and the data all on the same machine (albeit temporarily), which doesn't seem that great either.

Is one of these objectively better? Is there a better alternative than either?

frostcoinage
  • 11
  • 1

2 Answers2

1

If you are caching the key, there is always going to be some risk.

That risk can be mitigated by:

  • Restricting the amount of time the key is kept in memory
  • Restricting to dynamic memory only so that it is lost on page close
  • Using a hardware or virtual key store to make access to the key easier but more secure. Ubikey or Windows certificate store would be examples.

Private keys MUST NEVER be stored on a server unless they are themselves encrypted with a key that only the user has (making the process rather redundant). Once a users private key is stored on a server, it can no longer be considered secure.

Julian Knight
  • 7,092
  • 17
  • 23
0

You are making a lot of assumptions, many of which are wrong. The most glaring one is that the browser has exclusive control over when the cookie is expired. You can delete it in a server response whenever you want. You can store more than one piece of data in a cookie (like an expiry time and a signature to protect against modification. If someone has access to the memory and storage on the client during a session, then they have access to the data you are trying to protect. You don't have to store the cleartext of the key on the client to allow decryption at the server (you could use a further, session key generated on the server, although if the objective of not using a conventional http session is not capacity related, then there's little difference to just keeping the key serverside).

Using an http session simplifies a lot of other problems (like csrf).

As to which of these is better, or what might be more appropriate, that depends on your threat model.

symcbean
  • 18,278
  • 39
  • 73