Hashing is a computational process that condenses a message into an irreversible fixed-length value, or hash. A few examples include:
Practical applications include email PGP/GPG signatures, open-source software repositories (GIT), backups, software updates, Adobe’s Portable Document Format (PDF), and digital certificates used in websites, message integrity checks, file comparison, authentication, and data caching.
The cybersecurity value of hashing is captured in the following examples:
Hashed data caching | the hash represents one and only data block and prevents serving data cached for another business purpose
Hashed open-source software repositories | ensures code in the repository was not replaced by malicious code
Hashed Adobe Portable Document Format (PDF) | ensures the PDF has not been tampered with; this is the actual practical example that Google demonstrated
A good hashing algorithm should have a few properties:
1. Calculating the hash for a give data should be computationally easy.
2. Trying to calculate the data starting from the resulting hash should be extremely computationally difficult.
3. Two slightly different pieces of information should not result in the same hash
4. Minimal change in the inputted data should result in a completely different hash. Results should look random but be computed deterministically
SHA-1 is one of the most widely used of the existing SHA hash functions. However, SHA-1 has been “on notice” for more than 10 years.
In 2005, a method was found for uncovering collisions for SHA-1 within practical time frame making long-term employability of SHA-1 doubtful. At the time, the attack was considered theoretical but relevant enough for many security experts to discourage the use of SHA-1 in favor of SHA-256, SHA-384 and SHA-512.
Long before last week’s attack, Microsoft, Google, Apple and Mozilla have all announced that their respective browsers will stop accepting SHA-1 SSL certificates by 2017. The announcement of a practical collision attack on February 23, 2017 will likely be the last stab on SHA-1 to make the industry move away from it even faster. Google announced that starting with version 56, released this month, Google Chrome will mark all SHA-1-signed HTTPS certificates as unsafe.
Put simply, the SHA-1 collision allows computer to incorrectly determine two dissimilar pieces of data to be identical. For example, a good PDF file could be replace by a tampered version. A rogue website could create a digital certificate to pose as another entity, a digitally signed message could be forged, and a file downloaded from the Internet could be replaced by a malicious file and go unnoticed.
If a website uses certificates signed with SHA-1, they should consider replacing them immediately. Even if the organization thinks attacks are unlikely, browsers will warn users that the website is no longer trusted.
Digital signatures should also be upgraded. Security practitioners should work with vendors of applications in the categories previously mentioned to ensure they are safe. At the time this article was published, SHA-256 is an acceptable solution. Organization should also consider the newer SHA-3 standard, which has not been positioned as a replacement for SHA-2, but a backup as SHA-3 is very different from SHA-2 in design.
The simple fact that an application uses SHA-1 does not mean it’s instantaneously vulnerable. For example, Git makes deliberate use of SHA-1, however it prepends a type/length field to the data. This additional data point makes it very unlikely that a collision could be feasible as it needs to have the exact same length as the original data.
Lastly, whether your organization was impacted by the SHA-1 collision attack or not, if you develop software that uses cryptography, this is a good time to introduce the concept of cryptographic agility to your development teams. Crypto agility is the capacity for an IT system to easily evolve and adopt alternatives to the cryptographic primitives it was originally designed to use. With crypto agility, the encryption and hashing algorithms in the code are defined by strings in libraries that abstract the underlying implementation and not hard coded function calls. Because all cryptographic algorithms currently in use such as SHA-256 have a good chance of eventually being broken, crypto agility helps developers to move away from those algorithms more quickly and easily, as long as the library in use supports alternative algorithms and the data records can expand in size to accommodate larger hashes and encrypted data. Adding redundant checks such as data length, can hardener security as seen in Git’s example. Another good example is Bitcoins address implementation, which uses two different hashed algorithms (SHA-256 and RIP-MD160) on top of each other in an attempt to protect user’s identity.
About Cassio Goldschmidt
The Vice President, Cyber Resilience Practice at Stroz Friedberg, an AON company, Cassio Goldschmidt is an internationally recognized information security leader with strong background in both product and program-level security. Outside work, Cassio is known for his contributions to Open Web Application Security Project (OWASP) , Software Assurance Forum for Excellence in Code (SAFECode), the Common Weakness Enumeration (CWE)/SysAdmin, Audit, Network, Security (SANS) Top 25 Most Dangerous Software Errors, along with contributing to the security education curriculum of numerous universities and industry certifications.