Insecure Cryptographic Storage

Definition:

Web applications frequently use cryptographic functions to protect information and credentials. These functions and the code to integrate them have proven difficult to code properly, frequently resulting in weak protection.

Protecting sensitive data with cryptography has become a key part of most web applications. Simply failing to encrypt sensitive data is very widespread. Applications that do encrypt frequently contain poorly designed cryptography, either using inappropriate ciphers or making serious mistakes using strong ciphers. These flaws can lead to disclosure of sensitive data and compliance violations.

Protection:

The most important aspect is to ensure that everything that should be encrypted is actually encrypted. Then you must ensure that the cryptography is implemented properly. As there are so many ways of using cryptography improperly, the following recommendations should be taken as part of your testing regime to help ensure secure cryptographic materials handling:

• Do not create cryptographic algorithms. Only use approved public algorithms such as AES, RSA public key cryptography, and SHA-256 or better for hashing.

• Do not use weak algorithms, such as MD5 / SHA1. Favor safer alternatives, such as SHA-256 or better.

• Generate keys offline and store private keys with extreme care. Never transmit private keys over insecure channels.

• Ensure that infrastructure credentials such as database credentials or MQ queue access details are properly secured (via tight file system permissions and controls), or securely encrypted and not easily decrypted by local or remote users

• Hashing is not encryption. If an attacker knows what hashing algorithm is being used, he can do a brute-force attack to crack the hash value.

• Ensure that encrypted data stored on disk is not easy to decrypt. For example, database encryption is worthless if the database connection pool provides unencrypted access.

• Under PCI Data Security Standard requirement 3, you must protect cardholder data. PCI DSS compliance is mandatory by 2008 for merchants and anyone else dealing with credit cards. Good practice is to never store unnecessary data, such as the magnetic stripe information or the primary account number (PAN, otherwise known as the credit card number). If you store the PAN, the DSS compliance requirements are significant. For example, you are NEVER allowed to store the CVV number (the three digit number on the rear of the card) under any circumstances. For more information, please see the PCI DSS Guidelines and implement controls as necessary.

.Net Overview:
Cryptography itself is not that difficult to work with, but it is important to decide which algorithm to use. .Net framewokr has many Crypto classes. We mostly use these classes for diffrent senarios.

We do not chose MD5 or SHA1 for hashing since we learn that they are insecure.

We also have a low level coded dll for 3DES encrpytion. It is not a .Net dll. We use it for high performence business. It is faster than .Net classes.

Classes available for symmetric encryption. All classes inherit from SymmetricAlgorithm
Algorithm Cryptographic class Description
DES DESCryptoServiceProvider Wrapper class to access the standard CSP for the Data Encryption Standard (DES) algorithm
RC2 RC2CryptoServiceProvider Wrapper class to access the standard CSP for the RC2 algorithm
Rijndael RijndaelManaged Wrapper class to access the standard CSP for the Rijndael algorithm. The CSP is made of managed code.
TripleDES TripleDESCryptoServiceProvider Wrapper class to access the standard CSP for the Triple DES algorithm

Classes available for asymmetric encryption. All classes inherit from AsymmetricAlgorithm.
Algorithm Cryptographic class Description
DSA DSACryptoServiceProvider Wrapper class to access the standard CSP for the Digital Signature Algorithm (DSA) algorithm.
RSA RSACryptoServiceProvider Wrapper class to access the standard CSP for the RSA algorithm.

Classes available for hash functions.
Algorithm Cryptographic class Description
MD5 MD5CryptoServiceProvider Computes the MD5 hash for the input data using the implementation provided by the CSP.
SHA1 SHA1CryptoServiceProvider, SHA1Managed The classes compute the SHA1 hash for the input data using the implementation provided by the CSP. The former class uses unmanaged code; the latter is based on managed code.
SHA256 SHA256Managed Computes the SHA256 hash for the input data using managed code.
SHA384 SHA384Managed Computes the SHA384 hash for the input data using managed code.
SHA512 SHA512Managed Computes the SHA512 hash for the input data using managed code.

RijndaelManaged crypto = new RijndaelManaged();
byte[] Key = {...};
byte[] IV = {...};
ICryptoTransform trans = crypto.CreateEncryptor(Key, IV);
…

And our connection strings are encrypted in web.config. We use manual encryption and decryption in some senarios. And encrypt using machine Keys (RSA Keys) if posibbly.

configProtectedData>
providers>
add keyContainerName="CustomKeys"
useMachineContainer="true"
name="CustomProvider"
type="System.Configuration.RsaProtectedConfigurationPr
ovider, System.Configuration, Version=2.0.0.0,
Cultural=neutral,
PublicKeyToken=b03f5f7f11d50a3a"/>
/providers>
/configProtectedData>