Insecure Cryptographic Storage
This article is Part 8 in a 11-Part series about the Owasp Top 10.
- Part 1 - Understanding Cross-Site Scripting (XSS)
- Part 2 - Injection Flaws
- Part 3 - Malicious File Execution
- Part 4 - Insecure Direct Object Reference
- Part 5 - Cross Site Request Forgery (CSRF)
- Part 6 - Information Leakage and Improper Error Handling
- Part 7 - Broken Authentication and Session Management
- Part 8 - This Article
- Part 9 - Insecure Communications
- Part 10 - OWASP 2007 Top 10 Presentation
- Part 11 - Failure to Restrict URL Access
Insecure cryptographic storage occurs when an application doesn’t securely encrypt it’s sensitive data. This vulnerability is about data at rest. Data in transit is considered insecure communication not insecure cryptographic storage.
Insecure cryptographic storage occurs in the following situations:
- Developers don’t encrypt data being stored in the database.
- Developers encrypt data with homegrown encryption.
Many developers know they should encrypt their sensitive data; not doing so creates a code smell. But, many developers will create their own encryption methods rather than using ones which have already been developed. If you think you are smart enough to write your own cryptographic algorithms, you’re not. There is an entire encryption industry, with lots of peer review, to develop secure encryption methods. Developing a simple, easy-to-use, encryption algorithm is not easy.
Not encrypting sensitive data leads to confidentiality loss. All companies are concerned with unauthorized individuals viewing their sensitive data. In addition, encrypting sensitive data is a requirement by different regulations, such as PCI-DSS requirement 3.
An Example of Insecure Cryptographic Storage
Here is a simplified example. We have a database that contains a users table. If we return all of the columns from the users table we receive the following output:
> select * from users;
| id | username | password | |
|---|---|---|---|
| 1 | Brett | 5f4dcc3b5aa765d61d8327deb882cf99 | |
| 2 | Dan | 3c3662bcb661d6de679c636744c66b62 |
The passwords returned by the query are 32 characters long. Could these passwords be MD5 hashes?
As with all hashing algorithms, MD5 hashes can’t be reversed. However, they can be pre-computed. Using a hash table lookup we can identify what the password is before it was ran through the MD5 hashing algorithm.
Finding the hash, 5f4dcc3b5aa765d61d8327deb882cf99, in our hash table returns the password, password.
Preventing Insecure Cryptographic Storage
If the data is sensitive, it needs to be encrypted when at rest. Any time sensitive data is stored it NEEDS to be encrypted. Examples of information which is considered sensitive includes credit cards, usernames, passwords, and can include user-created data based on what your application does.
-
Remember to use standard methods for doing encryption. Use known secure encryption methods. Don’t create your own encryption algorthims. No matter how smart you, or your peers, are DO NOT attempt to invent your own encryption algorithm. Leave this work to the experts.
-
Ensure that the data stored is not easy to decrypt. This can usually be averted by not using known weak algorithms such as RC3, RC4, MD5 and SHA-1.
-
If you are using asymmetric key encryption make sure to store your private keys carefully. If an attacker gets hold of the private key, you might as well not encrypt the data in the first place.