Many sources explain about specific or minimum security requirements, e.g. PCI. Many organizations that must follow regulations think that the difficult job already done since the regulator already defined the security requirements for any system in the organization.
In this post I would like to refute this approach using examples.
Example #1 - Symmetric encryption standards
How does exactly PCI allow applications to use 3DES? The requirement for using this algorithm is double length key (2 x 156bit = 312bit). Ok, but it's still vulnerable to cryptoanalysis attacks.
BTW - Let's ignore the fact that 3DES is eight times slower than AES :-)
Moreover, I don't think that even requirement for AES with 256bit key is enough because:
1. By default, the cipher mode is weak (.NET use CBC) - NIST took it one step further and explained about the secure block ciphers. A weak cipher can still comply with most regulative requirements, but still be vulnerable to cryptoanalysis attacks as well.
2. Do you really think that with today's cloud computing resources, it won't be deciphered? It has been demonstrated in BlackHat DC 2011.
Note: PCI include AES configuration with at lease 128bit key length.
To conclude this example, I think that the newest algorithm and the longest encryption key must be used for most applications, i.e. AES with 512bit key length.
In addition, I think that also new mobile devices can handle this encryption. The exceptions in this case are old mobile devices and embedded ones, which have less computing resources.
Example #2 - Passwords management
Many systems store the password in an hash format, e.g MD5, SHA1, SHA256. In this case, there is requirement in PCI to store sensitive information using SHA1 and above.
The old news - there are also SHA-1 rainbow tables!!!
Can the organization comply to regulations that require SHA1? Yes.
Is the organization secure (not vulnerable to password guessing via SHA1 rainbow tables)? No.
The solution: use "salt" and implement SHA512 algorithm. I think that the maximum should be implemented because:
1. Even in Big-Data systems, the execution of SHA512 is not that expensive.
2. User authenticates once in a session - the rest is based on a session id. Hence, the hash function is performed only once per successful login.
Disclaimer: In this case I write about server-side. If hashing is performed on the client side, then it should be considered according to the hardware.
Secure = future ready
Everything is about risk management? Not really... Everything is about risk management and future readiness!
I think that organizations should not run after their tail and try to comply to the updated version of a specific regulation/standard. If organizations think about future readiness, they can be compliant and secure for at least the next following years.