2

Scenario

  • Master key is entered upon login then encrypted with $server_key
  • Master key is now stored as $_COOKIE['encrypted_key'] variable for persistence (so user doesn't have to enter it every page load)
  • $server_key is stored inside a config file in the app server
  • Data is decrypted by first decrypting $_COOKIE['encrypted_key'] (using $server_key), therefore revealing Master key
  • $_COOKIE['encrypted_key'] is destroyed upon browser exit

Threat

Attacker gaining access to user device/cookie and encrypted data (but not the app server config files).

Question

Does it make sense to encrypt the Master key with $server_key and then store $server_key inside a config file in the app server?

Reasoning

Gaining just the $server_key or just the $_COOKIE['encrypted_key'] will not compromise anything. The attacker must get both.

Update

  • This is under HTTPS
  • Session hijacking would be hard as we check session fingerprint per request
Improve this question
15
  • 1
    This is pretty similar to your question on SO
    – grochmal
    Commented Sep 12, 2016 at 0:14
  • Also, how are you going to encrypt the key in $_COOKIE['encrypted_key'] in the first request from client to server if the master key is on the app server?
    – grochmal
    Commented Sep 12, 2016 at 0:17
  • @grochmal The app simply requests for it e.g., get_key_from_config()
    – IMB
    Commented Sep 12, 2016 at 20:14
  • That's what I thought, but how do you prevent an attacker from simply requesting it. i.e. Hey server, i'm app 1234. Give me the key to encrypt my stuff. And then the attacker simply decrypts the cookie.
    – grochmal
    Commented Sep 12, 2016 at 21:05
  • @grochmal This is a web app. To do the thing you describe means the attacker gained root access already.
    – IMB
    Commented Sep 12, 2016 at 21:11

2 Answers 2

Reset to default
6

Your threat model is incomplete. Here are some of the things you missed:

1) The master key and server key appear to be static values. This means the cookie value is constant and anyone that has the cookie value can replay it to the server to steal (spider) all the plaintext data for that user.

1a) Cookies gets stored in other locations too such as proxies.

2) If the server is compromised an attacker can brute force the master key space to decrypt the user data on a per user basis. The success chance of this depends entirely on the master key length and encryption algorithm.

3) A user can derive the server key. As they know the master key and can view the cookie they can brute force the server key offline. Again success factor is dependant upon key length and algorithm.

4) It's unclear if the service is being delivered over an encrypted of plain text connection. In the case of the latter both the master key and cookie value can be observed by an attacker on the same network. If the former the connection may be downgraded or other vulnerabilities may exist.

5) If the attacker hacks the server they can modify the login code to keep a copy of all master keys it receives. It is common for breaches to go unnoticed for months/years.

Improve this answer
5
  • 1. Correct me if I'm wrong but aren't keys static in nature? Otherwise you have to re-encrypt everything all the time. The purpose of the $server_key is to defeat cookie replays, they can replay but they don't know the $server_key.
    – IMB
    Commented Sep 12, 2016 at 20:26
  • 2. I agree although bruteforce requires knowing the algo used and serious will/compute power
    – IMB
    Commented Sep 12, 2016 at 20:27
  • 3. Sorry I don't get this because the user cannot derive the $server_key at all. The app handles encrypt/decrypt in the server side. The only thing the user has in his browser is $_COOKIE['encrypted_key']
    – IMB
    Commented Sep 12, 2016 at 20:27
  • 4. It is using HTTPS
    – IMB
    Commented Sep 12, 2016 at 20:27
  • 5. I agree. To complete data breach, the attacker must do 3 things: obtain $server_key, obtain $_COOKIE['encrypted_key'], obtain database access.
    – IMB
    Commented Sep 12, 2016 at 20:28
1

The purpose of the $server_key is to defeat cookie replays, they can replay but they don't know the $server_key

Encrypting the master key with server key doesn't defeat replay attack. The attacker can just send the send the encrypted master key to your server and have it decrypt whatever data the attacker wanted. Your server becomes a confused deputy. The attacker doesn't need to compromise the server or obtain the server key to do this.

To limit this attack, you can add an expiry date and IP address inside the encrypted master key, i.e. Encrypt(MasterKey + Expiry + IP address), your server should only use the encrypted token if it is not expired and the request comes from the given IP address.

Improve this answer
7
  • Can you explain how can the attacker replay the session on his machine given that we have HTTPS + session fingerprint checks?
    – IMB
    Commented Sep 13, 2016 at 12:41
  • 1
    @IMB: if you assume the threat model is that both ends of the communication are secure, HTTPS already protects against replay attack. Additional encryption of the master key that's already inside HTTPS does not confer any extra protection. Given that the extra extortion doesn't really add any extra protection, the encryption is just extra, unnecessary complexity. If your threat model involves the client side being possibly compromised, then just encrypting the master key is insufficient to protect against replay attack.
    – Lie Ryan
    Commented Sep 13, 2016 at 13:18
  • @IMB: my point is that you should either just simplify the code and remove the unnecessary master key encryption; or if you want to take client compromise into account, you should go all the way and encrypt the master key and the session fingerprint (e.g. IP, expiry date, capabilities) together to mitigate replay attack.
    – Lie Ryan
    Commented Sep 13, 2016 at 13:39
  • @IMB - session fingerprint is poor security (unless you're using something like full passive fingerprinting). I need to argue that your thread model is horrible: you keep adding more "tinfoil" as people point the holes in the threat model and then we poke more and more holes in the tinfoil. You need to put all pieces together (and I mean all of them) into the question text and think it through. I do not mean it as a bad thing: just the exercise of putting all those pieces together will make the picture clearer for yourself.
    – grochmal
    Commented Sep 13, 2016 at 21:15
  • @grochmal What tinfoil am I adding? Am I not adding things as we go, they are really there beforehand, I just didn't explicitly say them because I assume they are common sense for things like this e.g., SSL.
    – IMB
    Commented Sep 14, 2016 at 1:32

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .