Sensitive Data Exposure

Description

Sensitive Data Exposure is a class of software vulnerability where important application or system data is not properly protected. Sensitive Data should be stored encrypted or protected wherever possible, with secure algorithms and strong key management. The most common flaw is simply not encrypting sensitive data. When crypto is employed, weak key generation and management, and weak algorithm usage are both common, particularly weak password hashing techniques.

While attacks against this vulnerability are possible, they are often uncommon due to limited access by attackers and can be difficult to exploit remotely. However, using weak encryption means attackers will be able to compromise data captured after the fact.

Bug

TaskManager makes a common mistake when storing passwords in the database; while the passwords are hashed, they are stored using the insecure hashing algorithm MD5. If an attacker compromises the database and reveals the password hashes, they will be able to quickly compromise user passwords.

Solution

Instead of using the MD5 hashing algorithm to store passwords, use a hash designed to be computationally intensive, such as bcrypt or PBKDF2. These hashes will ensure that even if an attacker compromises your user database, the passwords cannot be feasibly cracked.

In django, upgrading the password hash is as easy as changing PASSWORD_HASHERS in the settings.py line. Replace 'django.contrib.auth.hashers.MD5PasswordHasher' with 'django.contrib.auth.hashers.PBKDF2SHA1PasswordHasher' or 'django.contrib.auth.hashers.BCryptPasswordHasher'.

MD5 is insecure because it was designed to be as fast as possible. Attackers are able to try millions or billions of passwords a second against the passwords in your database using readily-available hardware. In constrast, bcrypt and PBKDF2 are designed to be slow. For servers, a login may take 2 seconds rather than 1. But for an attacker, testing a million hashes now requires a million seconds!

Hint

How secure is this site anyways? Are my credentials really protected?

Find that injection vulnerability yet? Django stores user passwords in the auth_user table. Something isn't quite right about them.