3 Common Encryption Mistakes That Are Easy to Avoid - Ubiq (2024)

At Ubiq Security we focus on data security and making it easier for developers to incorporate encryption into their applications. As part of ourwork,we spend time on Slack, Stack Overflow, Reddit, etc. and we seeseveralcommon mistakes that can cause security vulnerabilities that areeasyto resolve. While we don’t think any developer wants to make an insecure product, it is easy to understand how developers not experienced in data security might not realize the impact of grabbing some sample code from the Internet and incorporating it into their application. I often say that writing programs incorporating encryption or data security is not like other software development. Just because an application runs, doesn’t mean you are done or that your application is secure.

Common Encryption Mistake #1 – Inadvertently reducing the range of a hashed value

I have lost count of how many times I have seen someone use sha256 thinking they are creating a256-bitvalue stored in 32 bytes whentheyareactually creatinga 128-bit value stored in 32 bytes.

Look at code snippet below.

KEY = sha256(<some-value>).hex.substr(0,32)

Since the snippet begins with sha256, the developer’s intent appears to be to create a 256-bit key stored in the 32 bytes. However, this code snippet is literally taking a256-bitvalue and reducing it to only 128 bits.

You may have already identified the problem, but let’s walk through it.

• sha256 produces a 32 byte value with each byte having 256 unique values, meaning 256³² possible (which is the same as 2²⁵⁶).
• The next step in the code is encoding the results of the hash into hexadecimal which returns a string of 64 characters, with each character having 16 unique values: a hex character [0-9a-f]. This means the string contains 16⁶⁴ possible values (which is the same as 256³²) so we haven’t lost any precision yet.
• The issue is the substr(0,32) which takes only the first 32 hex characters in the string, meaning that KEY only has 16³² possible values (which is the same as 2¹²⁸).

Potential Impact:Simply put, the impact is probably catastrophic. Instead of deriving a 256-bit value, the result is only 128 bits. The following article explains the difference between128 and 256 bit encryption keysbut for simple reference, the difference between 128- and 256-bit valuesisroughly a factor of the number 3 followed by 38 zeros.

Solution: Besides more thorough and good code reviews?Don’t think of keys or hashes as a string of characters. Think of them for what they are, an array of bytes. If you need to debug, print, display, or transmit the value, only convert to the necessary form at that time.

Using python as an example:

Incorrect

key = hashlib.sha256(b"<somevalue>").hexdigest()[0:32]# debug codeprint(key)

Correct

key = hashlib.sha256(b"<somevalue>").digest()# debug codeprint(key.hex())

Common Encryption Mistake #2 – Using a hash rather than HMAC

This one is a little more subtle, especially to those who are new to using cryptographic algorithms. Look at the code snippet below.

signature = sha256(Key + Message)

The forum topics and related code indicate an intent to create a signatureas a way toverify message authentication and integrity. Unfortunately, most of the common hashing algorithms such as SHA256 are vulnerable to alength extension attackwhich, simply stated, means:

Hash(Key + Message) can be used to deriveHash(Key + Message + extra) even if the secret Key value is not known.

Potential Impact:The impact of this attack means that the receiver cannot detect if the message has been altered. An attacker can intercept a message and signature, modify the message, derive a new signature, and forward the modified message and signature to the receiver; and the modification would not be detectable.

Not all hash functions are subject to a length extension attack, but unfortunately, the ones that are include SHA256 and many of the other common hash functions.

Solution: Use the right function – HMAC

HMAC –This standsforHash-basedMessageAuthenticationCode which is used to prove message authenticity and that the message hasn’t been altered between a sender and receiver. Fortunately, the HMAC function is explicitlydesignedto produce a signature and is not susceptible to alength extension attack, regardless of the hashing algorithm.

A HMAC typically has three inputs, aKey, aMessage, and ahashing algorithm. The key and message are combined and processed with the hashing algorithm to produce the message signature. If the Key value is secret, it is pretty much impossible to alter the message or signature without detection.

Using python as an example:

Incorrect

signature = hashlib.sha256(Key + Message)

Correct

signature = hmac.new(Key, Message, hashlib.sha256)

Common Encryption Mistake #3 – Inadvertently allowing Hash data collisions

Let’s face it, one of the great features of a good secure hashing algorithm is being collision resistant.This means that there is an extremely unlikely chance that two different inputs will produce the same hashed output.However,hashing algorithms are deterministic,meaning that for the same input, they will alwaysproducethe sameoutput.

Consider this code snippet:

hash(<customer-name> + <customer-ids>)

On the surface, this looks fine, the customer supplies their name, and maybe we force all customers in the DB to be unique. The customer-id is a database sequencer and is guaranteed to be unique, so the developer may be making an incorrect assumption that there is a high likelihood that the result of the hash should be unique. Unfortunately, because the customer provides input to one of these values, they control one of the hash inputs and therefore can have some control over the output and potentially induce hash collisions. Remember thatall ofthe following statements produce identicalresults even thoughthe customer-name and customer-id are unique values.

hashlib.sha256(b"acme-tech" + b"1234").digest()hashlib.sha256(b"acme-tech1" + b"234").digest()hashlib.sha256(b"acme-tech123" + b"4").digest()

Potential Impact:We should all remember that we live in a world where an attacker’s goal is not always to get your data. Sometimes they just want to disrupt your business or prevent you from accessing your own data. If a data collision causes your system to break and they can induce this condition, then they have succeeded. Don’t make it easier for them.

Solution:The developers need to be very careful when hashing values where the user has any direct control over even one part of the hash input. Simplyreplacingthecustomername with a UUID stored in the DB would solve this issue. The UUID may beknownby the customer,but since it isn’t under their control the risk of attacker influenced hash collision would be avoided.

Incorrect

value = hashlib.sha256(customer-name + customer-id)

Correct

value = hashlib.sha256(customer-uuid + customer-id)

Although this article focuses onsome common encryption mistakes and their relatively simple solutions, it easily could have listed many more that are much less obvious or more difficult to resolve. You may start to get an appreciation of how even a slight mistake or oversight can introduce data security vulnerabilities into your application. The Ubiq Platformis designed to avoid the complexity and mistakes that are related to data encryption.Ubiq constantly monitors the latest research related tocryptographicalgorithms,including encryption and hashing,andany newly discoveredvulnerabilities, and it incorporates the newest information into the platform, ensuringyourdata remains as secure as possible.

To see the Ubiq Platform in action, check outthisdemo.