Missing encryption

Missing encryption (of sensitive data) is a software weakness that leads to a break in the confidentiality and/or integrity of data because it is not encrypted properly. When sensitive information, such as passwords, credit card numbers, personal identification numbers (PINs), or other confidential data, is not encrypted during transmission or storage, it becomes vulnerable to interception and unauthorized access. This vulnerability can lead to various security breaches, including data theft, privacy violations, and unauthorized transactions.

In this lesson, you will learn about the dangers of missing encryption and how to protect your application from it by properly implementing encryption of sensitive data. We will step into the shoes of Lily, who was able to break into her father's lottery account via a weak password reset implementation.

This clearly isn't the right way to do a password reset and this type of attack shouldn't happen. But why did it happen? Let's take a look at the code.

The key problem here is that the password reset token is generated via base64 encoding and not any form of encryption. At first glance, it may look like a jumble of unpredictable text, but it is fact predictable. The user could easily take the token and manipulate it so that it contains someone else's email address, and take over anybody's account as we saw in the example above.

Missing encryption could result in the lack of confidentiality and integrity of data. In this case, the password reset link is only sent to the email address of the user that requests it; to be able to view their own email address via base64 decoding is not much of a break of confidentiality, unless the link is leaked somehow (e.g. through browser history on shared computers, use of a proxy controlled by a third party, or uploaded to a URL scanning service that inadvertently exposes it to the public).

The impact of lack of integrity is more severe in this case, as the application is taking encoded input from the user and treating it as trusted, leading to an account takeover of any user on the website.

To mitigate this issue, we should apply cryptography in a thoughtful way that prevents the modification of the email address in the password reset token. We could implement a unique ID or if we might want to store the email in the token, so that a massive database to store all reset tokens isn't required.

To protect the integrity of the data, we should utilize a technique called signing. A popular way to implement signing is called JWT (JSON Web Tokens), which can utilize a range of encryption and hashing algorithms to ensure that the original plaintext message is intact. In this case, we can use symmetric cryptography with a secret key kept on the server side called HS256 (HMAC with SHA256) to sign a hash of the plaintext data. That way, if the email address was modified, the signature would be invalid and the application can reject the token.

The implementation of using JWT for password reset would look like this:

Now that we are validating the data in the token, there's no way for someone to change the email address inside it and reset someone else's account password.

Learn more about encryption and hashing!

• The CWE page matching this vulnerability type: https://cwe.mitre.org/data/definitions/311.html
• Our Snyk Learn lesson on insecure hash