4

Use Case

I would like to encrypt data in a database for a Web Application. The following requirements exist:

  • Decryption should only be possible when a user provides a passphrase
  • Encryption should always be possible

I therefore use asymmetric encryption using public and private keys. An encrypt operation can be launced by the web app at any time, but the web app can only decryption when the user provides a passphrase.

Problem

All of this works fine, but the problem I have is that everytime the user wants to decrypt data, he needs to provide a passphrase. I would like to provide the user with the option to "remain authenticated" for a session, after he enters the passphrase once.

Here is where I am having trouble. If I decide the store a hash of the passphrase in the Session, then the server would technically be able to decrypt the data without the user's Input. Remembering a passphrase hash in a Cookie is also not an option.

What common options do I have? Is it possible that my approach overall is incorrect?

Possible Solution?

After some thinking I plan to implement the following:

  • User sends passphrase to server
  • Server creates a random 128 bit key
  • Server hashes the passphrase and encrypts it with the new random key using AES
  • Encrypted hash is then stored in the session at the server
  • The Users stores in his cookie: Session ID and Encryption Key
  • Only when both are provided with a request, can the server decrypt the data
  • The session will become invalid after a certain time period

Is this a secure approach?

The Data can only be decrypted if:

  • Encrypted Data is retrieved
  • Private Key is retrieved
  • Session Data is retrieved
  • User Cookies are retrieved

Notes:

  • The data itself is not encrypted with the public key, but a random key is generated and used to encrypt the data using AES. This key is then encrypted with the public key, which allows for some form of user management.

  • Everything runs in HTTPS

  • The private key is encrypted with a hash of the passphrase, not the passphrase itself

Thanks in Advance

1

What you've described is very similar (almost identical) to the basics of the OpenPGP standard. It would be wise to read up on OpenPGP before attempting your own implementation of this scheme.

To answer your question posed here:

Here is where I am having trouble. If I decide the store a hash of the passphrase in the Session, then the server would technically be able to decrypt the data without the user's Input. Remembering a passphrase hash in a Cookie is also not an option.

This is a tautology. As long as you don't maintain a ciphertext in/out paradigm for your server it will always be able to decrypt stored data at some point. The best you can do is require user input for every operation.

  • thanks for the tip. PGP seems to do exactly what I am doing manually. I will probably use it. But regarding the session management. You are of course right, the application at some point needs to know how to decrypt data. I just want to limit this to when the user actually requests the data. I doesn't make sense to me that the application should technically be able to decrypt the data for 90 minutes straight. At the same time I don't want to prompt the user for a login every 15 minutes. Is ist common to store session decryption Keys in cookies? Are there better ways? – nanotvi Oct 27 '14 at 16:29
  • @nanotvi You might want to look into generating session tokens using a mechanism like OAuth. However, there is a lot of added complexity when implementing this. – RoraΖ Oct 28 '14 at 15:05

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.