Last year, the SHA-1 algorithm was broken by the Cryptology Group at Centrum Wiskunde & Informatica, the national research institute for mathematics and computer science in the Netherlands, and the Google Research Security, Privacy and Anti-abuse Group.
The news didn't come completely as a surprise to the cyber community, since it was well-known that the algorithm was vulnerable to theoretical attacks; in fact, it had been officially deprecated by NIST in 2011. Many frameworks kept supporting it despite the deprecation, and others even encouraged its implementation.
SHA-1 is a relatively fast cryptographic hashing function that supports many security mechanisms, such as authentication and data integrity. Among the things that depend on the security of such algorithms are hashing passwords on databases, authentication mechanisms, and digital certificate verification.
Now that there is a practical way to break SHA-1, you might expect that frameworks and the products that provide methods to use them would be warning developers against implementing it or, even better, disabling it entirely. Unfortunately, what happens in the cyber community does not rise to the development community very quickly.
Here's what your application security team needs to know to avoid getting stung by SHA-1.
SHA-1 lives on in libraries
Examples of this are the XMPP and ejabberd libraries. Although XMPP is well-known and considered a very strong and secure protocol, particularly in chat and messaging software, the XMPP wiki documentation has not been updated to reflect the SHA-1 issue. This is a problem, since the component in question has very sensitive functionality in authentication methods such as SASLandSCRAM-SHA-1, whose documentation was last updated in 2015 and therefore does not mention anything about the weakness of SHA-1.
Database dramas
MongoDB, a popular nonrelational open source database, also has outdated documentation that encourages developers to use MongoDB as a secure authentication schema, although for authentication purposes the open-source solution uses the SCRAM-SHA-1 mechanism, which combines SHA-1 with the Salted Challenge Response Authentication Mechanism (SCRAM). Most developers aren't aware that SHA-1 has been declared insecure, and make the mistake of using it. And again, many frameworks, including .NET, Java Spring, and NMP, do not have any warnings at all regarding the insecure nature of SHA-1. PHP documentation, on the other hand, has done this properly.
Enter the transport layer
According to the RFC 5802 that defines SCRAM: "The secure authentication mechanism most widely deployed and used by Internet application protocols is the transmission of clear-text passwords over a channel protected by Transport Layer Security (TLS). There are significant security concerns with that mechanism, which could be addressed by the use of a challenge response authentication mechanism protected by TLS."
This means that implementing SCRAM with SHA-1 won't add any extra protection for passwords transmitted through TLS.
Understand the risk
When authentication mechanisms deployed in production environments use SCRAM-SHA-1, the passwords use an insecure hash functionality. As an example of what can happen, in a man-in-the-middle attack (MITM), a hacker intercepting these hashed passwords would be able to regenerate the encrypted password.
Risks mount when other worrying discoveries, such as the broken WPA2 protocol, are thrown in.
Keep in mind that, should you address this problem by deploying a secure algorithm, users will need to reset their passwords. And since SHA-1 is a fast algorithm, it could adversely effect performance.
Why does insecure crypto persist?
Considering the high risk of using SHA-1, why are there no warnings that might ensure that developers avoid it at all costs? Given that theoretical attacks were possible in SHA-1 long before it was broken, and that NIST discouraged its use seven years ago, you have to conclude that such breakthrough discoveries have not been taken seriously in the open-source communities that support major software.
We have to start taking these discoveries seriously, even when attacks are merely theoretical. Algorithms such as RSA and AES are overly dependent on complexity, meaning they can be broken using enough brute force. They remain secure only because the required brute-force power is currently not within reach of attackers. That's today; in a couple of years, things could change.
Developers must accept the fact that the speed and convenience of SHA-1 does not compensate for the security hit. And business leaders must measure cyber risks properly. Attacks and broken protocols are becoming the norm in the world of cybersecurity, and they must acknowledge that fact so that software development can become safer.
Do you still have SHA-1 in use? Post your thoughts and comments below.
Keep learning
The future is security as code. Find out how DevSecOps gets you there with TechBeacon's Guide. Plus: See the SANS DevSecOps survey report for key insights for practitioners.
Get up to speed fast on the state of app sec testing with TechBeacon's Guide. Plus: Get Gartner's 2021 Magic Quadrant for AST.
Get a handle on the app sec tools landscape with TechBeacon's Guide to Application Security Tools 2021.
Download the free The Forrester Wave for Static Application Security Testing. Plus: Learn how a SAST-DAST combo can boost your security in this Webinar.
Understand the five reasons why API security needs access management.
Learn how to build an app sec strategy for the next decade, and spend a day in the life of an application security developer.
Build a modern app sec foundation with TechBeacon's Guide.
