Timofey-Makhankov/OWASP-Cryptography
1
0
Fork 0
generated from Timofey-Makhankov/Node-Express-JS-Template
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
main
OWASP-Cryptography/doc/Task.md
Timofey-Makhankov 873f25e150 updated sources
2025-05-19 16:45:11 +02:00

7.1 KiB
Raw Permalink Blame History

OWASP - Cryptographic Failures

Overview

Cryptographic Failures is one of the OWASP's Top 10 Items for Security and safety of Software. It is positioned as the second most important issue to be aware as a risk for an Application. This Document will describe: what it is, what are the risks and what can be do to prevent a security risk.

What is a CWS? not confused with a CVE

A CWE, or Common Weakness Enumeration, is a Community developed list of Software and Hardware weaknesses, that can become a security risk or vulnerability in an application.

Connection to the OWASP Top 10

For a given Item in the Top 10, it has associations to different CWS's. This allows for a detailed view of what kind of weaknesses can be found for a given item.

In this case: Cryptographic Failures has CWE-261: Weak Encoding for Password and more described here

What are the OWASP Proactive Control have to do with the Top 10?

The Top 10 List creates awareness of what risks and vulnerabilites can arise, if no care for security is given. The OWASP Proactive Control is a resource, were developers can learn, how to secure their Software. There are 10 Subjects, which have a connection to the OWASP Top 10.

For the Cryptographic Failures in the Top 10, there is a Subject in Proactive Control named C2: Use Cryptography to Protect Data

Failures of using Cryptographies

There are four main failures, when trying to implement Cryptography for an application

Weak Algorithms

This is one of the simplest failures that can arise. The use of Weak Algorithms. We schould try to not and try to stop using old and exploitable Hash algorithms for different purposes. The most popular is of course MD5, but it also includes SHA-1 and old versins of TLS and SSL.

This is especially true, if you are trying to store passwords in a database or trying to secure your site.

The two Main concerns are:

Exploits from high usage (Rainbow Tables)

One Issue can come, where either the Algorithm is compromised either through an exploit or from a Backdoor (RSA Backdoor). A different way is when an Algorithm were and are so highly used, that of many data breaches, that people now can create a list of common passwords hashes and their small changes in a rules file, that they can easily crack a hash in minutes or even seconds. This is particularly an issue with MD5

Hash Collisions

Hash Collision happens, when given two completly different input result in an exact Hash result. This is of course a rare occurance, But an issue can come, if an Algorithm doesn't use a long enough size for the hash.

For this Example, MD5 uses 128 bits to create a hash. this in turn has the ability to create 2^128 unique hashes, given an input. This is not the case, when trying to figure, when a hash collision happens. In short, it is half of the bits. so in turn it is 2^64. this is of course still a lot, but given that there are more accounts than people on earth or millions of documents are created every minute. It is not hard to see, how it can come to a collision.

A collision can become a problem, when trying to verify a trused document. If a bad actor can send a completely different document with a same hash, then how can you trust, that that document can be trusted.

Possible solutions

Try to use more modern Hashing Alogrithms or try migrate to one. Either SHA-2 and it derivatives and use the latests SSL and TLS.

For Passwords specifically, it is best used Bcrypt. This is because it can easily implement salting and peppering to encrypt a password. Salting makes it hard to use a rainbow table and peppering makes it hard to brute force an encrypted password, when the DB is compromised

Key Management

Keys are hard to manage, very similar to passwords. We are always said, that we should never save a password anywhere on a computer and not in plaintext. this is of course also true for any API keys or other Keys, that an application can use.

This can become an issue, when you use a key to authenticate to a service and is hardcoded in your projects control history. This allows for anyone to use that key, that should be using it

Possible solutions

NEVER STORE KEYS IN A REPO or have them be used anywhere you want

either use a .env file and never commit it to source history or you can use dotenvx to encrypt your environment variables and only have to worry about one key. Similar to a password manager, but for keys

to Prevent accidentall inclusions of a key, you may try this FOSS tool: Gitleaks. This checks, when a key has been committed and disallows to push your changes, unless removed from the commit

Predictable RNG

Sometimes we need to use a pseudo-random number Generator for either creating salts or other security reasons. This is sadly not optimal, because they are only "pseudo", if used incorrectly, then a bad actor can figure out, what the next value from that RNG can be and exploit it

Possible solutions

either don't use a RNG for Security or use one, that is not easily Predictable

for JS/TS, you can use crypto.getRandomValues() instead of Math.random()

Reuse of Keys / easily accessable keys

There are times, when we may be lazy and reuse a password we now. This also true when using keys to authenticate.

This can also come to an issue, if a system is already compromised and the bad actor has a key to a system and encrypted data. If he finds out, that he can use the found key to get a diffrent key to decrpyt data, then that is an issue

Possible solutions

DON'T REUSE KEYS. Generate new ones and have them be only used for a single purpose

Conclusion

Secuirty is evolving rapitly. To be secure, you need to always be aware of new security vulnerabilites and recommendations and update your software to latest versions.

Here is also a list of tools from OWASP, which check your applications for vulnerabilites and risks: Link

Sources