What we know so far about cryptographic vulnerabilities

Weak or home-grown algorithms

A common mistake developers make is to use weak or flawed encryption/hashing algorithms. For example, many developers use md5 or sha1 as their hashing algorithm of choice.

Using a md5-signed SSL certificate is not a good idea as it is vulnerable to numerous attacks such as collision attack through which attackers can create a rogue CA (certificate authority) that could be trusted by some common browsers. Luckily, md5-signed SSL certificates are disappearing from the horizon.

If you absolutely want to use md5 for sensitive data such as passwords do not do it without a proper unique salt for each password. There exist many websites offering free lookup of md5 and SHA1 hashes in large rainbow tables. Rainbow tables are just that – tables which contain the plaintext string and the hashed variation of that string. Let us take one of the existing websites with rainbow tables: hashkiller.co.uk. The website claims it has 43.745 billion decrypted md5 and SHA1 hashes in its database. If you do not use a salt (a random string usually prepended to the password), it is highly likely that many of your user’s passwords are in that database and if someone gets access to your database’s contents – he could get their password’s plaintext variation and log in as any user he wants.

We got the md5 hash of a sample password: echo md5(“Hello”); which turned out to be 8b1a9953c4611296a827abf8c47804d7 and asked hashkiller to show us the plaintext behind this hash and indeed it gave us just that:

Insufficient randomness

Functions exposing random generators in PHP such as rand($min,$max) and mt_rand($min,$max) should not be used for cryptographic purposes such as cryptographic keys as they are just not random enough. However, if you just want to display a random popup, search result, page or something like that which is not related to cryptography you should feel free to go ahead and use those random generators.

For cryptographic purposes, it would be better to rely on the OS native random generator (such as the /dev/urandom on a Linux machine and the crypto-api on a Windows machine) or a third-party library.

Other cryptographic issues

Many of the vulnerabilities we discussed within the context of authentication can also be found when dealing with cryptography. It is not a good idea to hardcode in the code or in a configuration file your cryptographic keys, nor is it a good idea to allow too long key aging, store the key in plaintext or put it unencrypted in transit.

As we discussed just a few lines above, it is not a good to use random generators with insufficient randomness or use too short cryptographic keys or use weak algorithms.

You may also like:

Weak or home-grown algorithms

Insufficient randomness

Other cryptographic issues

Related Posts