This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org

Difference between revisions of "Talk:Cryptographic Storage Cheat Sheet"

From OWASP
Jump to: navigation, search
m
(3DES)
 
Line 15: Line 15:
  
 
Yes, sysadmins do need a way to rotate keys quickly after they discover they were compromised.  But blindly rotating on a periodic basis just to make you feel better is a waste of time, when it comes to encryption of data at rest.  (Encryption in transit can be a different story.)  "But it doesn't hurt, right?"  Well, actually it does.  People could spend that effort on useful things, rather than on building and testing periodic key rotation systems.
 
Yes, sysadmins do need a way to rotate keys quickly after they discover they were compromised.  But blindly rotating on a periodic basis just to make you feel better is a waste of time, when it comes to encryption of data at rest.  (Encryption in transit can be a different story.)  "But it doesn't hurt, right?"  Well, actually it does.  People could spend that effort on useful things, rather than on building and testing periodic key rotation systems.
 +
 +
==3DES==
 +
Should we still even mention 3DES?  [[User:Pawel Krawczyk|Pawel Krawczyk]] ([[User talk:Pawel Krawczyk|talk]]) 07:25, 17 May 2017 (CDT)

Latest revision as of 12:25, 17 May 2017

I take issue with these two rules:

Rule - Build support for changing keys periodically
Key rotation is a must as all good keys do come to an end either through expiration or revocation. So a developer will have to deal with rotating keys at some point -- better to have a system in place now rather than scrambling later. (From Bil Cory as a starting point).


It is definitely a good thing for a system to have a built-in method for key rotation, when needed. What I take issue with is framing this as a "periodic" necessity. Changing out well-chosen encryption keys used for data storage on a periodic basis is almost certainly a waste of time and effort. Yes, if a key is compromised for whatever reason then we need to change it quickly when we find out about that, but blindly doing it on a monthly, quarterly, or whatever basis still exposes the data to attack 50% of the time. See more below.

Rule - Rekey data at least every one to three years[edit]
Rekeying refers to the process of decrypting data and then re-encrypting it with a new key. Periodically rekeying data helps protect it from undetected compromises of older keys. The appropriate rekeying 
period depends on the security of the keys. Data protected by keys secured in dedicated hardware security modules might only need rekeying every three years. Data protected by keys that are split and stored on two application servers might need rekeying every year.


Suppose a breach happens on the 10th of the month, but you normally rotate keys on the 25th. If you didn't find out about the breach until the 30th, then that is 15 days for the attacker to export the whole encrypted database and begin cracking it offline. What's more, after you automatically rotate the encryption keys for data at rest, the attacker *still has the data encrypted with the old key*. So they can just continue cracking offline. What did periodic key rotation buy you? The more you analyze this problem with a real threat model, the more you realize it buys you nothing.

Yes, sysadmins do need a way to rotate keys quickly after they discover they were compromised. But blindly rotating on a periodic basis just to make you feel better is a waste of time, when it comes to encryption of data at rest. (Encryption in transit can be a different story.) "But it doesn't hurt, right?" Well, actually it does. People could spend that effort on useful things, rather than on building and testing periodic key rotation systems.

3DES

Should we still even mention 3DES? Pawel Krawczyk (talk) 07:25, 17 May 2017 (CDT)