Why you should care about an old hashing algorithm

Jun 01, 2015


It has been some years now since the US National Institute for Standards and Technology announced that the SHA-1 encryption algorithm should no longer be regarded as secure and required US federal agencies to move away from its use, so why does this now matter to senior business officers?

The answer is that SHA-1 is used in the certificates that guarantee to your customers that they are visiting your web site and not a fraudulent copy. The browser recognises that the web site is presenting a valid certificate and responds accordingly, including triggering the padlock symbol in the browser or turning the address bar green.

On the first of January 2017, Microsoft Internet Explorer will stop supporting certificates that use the SHA-1 algorithm. Google have taken a slightly different approach with Chrome, which varies according to which version of Chrome a user is using and the expiry date of the certificate. Chrome users may already start to see a yellow warning triangle across the padlock or even see a red ‘x’ and a red line through the letters ‘https’. It is not hard to see that this may stop many customers from proceeding resulting in lost business. At the very least, if customers do proceed, they are being ‘trained’ to ignore security warning signals.

So why not just replace all the certificates with ones using the SHA-2 algorithm? The problem here is that some old browsers don’t recognise SHA-2 so won’t show the web site as secure. For example, any users still using Windows XP, estimated by security vendor Kaspersky in August 2014 to be 16% of users, will have this problem if they have not applied Windows XP Service Pack 3 which supports SHA2 certificates.

So there is a business decision to be made around staying with SHA-1 and having some users not trust your web site or moving to SHA-2 where users may not be able to use it.

The PCI Security Standard Council has already stopped the use of SHA-1 in card readers and the latest version of PCI DSS, v3.1, prohibits the use of SSL from 30 June 2016, so organisations will need to upgrade to a suitable version of Transport Layer Security (TLS) to maintain compliance. Although the PCI DSS standard does not explicitly prohibit SHA-1 in TLS certificates, it does recommend that organisations refer to the NIST guidelines for TLS implementation as they upgrade their infrastructures from SSL to TLS. This NIST standard does not recommend the use of SHA-1 in certificates and it is therefore likely that such use in a PCI DSS environment would be thrown up as an error in security testing, resulting in a compliance failure. The use of SHA-1 for hashing credit card data in storage would also result in a PCI DSS compliance failure.

What can you do?

It has been some years now since the US National Institute for Standards and Technology announced that the SHA-1 encryption algorithm should no longer be regarded as secure and required US federal agencies to move away from its use, so why does this now matter to senior business officers?

The answer is that SHA-1 is used in the certificates that guarantee to your customers that they are visiting your web site and not a fraudulent copy. The browser recognises that the web site is presenting a valid certificate and responds accordingly, including triggering the padlock symbol in the browser or turning the address bar green.

On the first of January 2017, Microsoft Internet Explorer will stop supporting certificates that use the SHA-1 algorithm. Google have taken a slightly different approach with Chrome, which varies according to which version of Chrome a user is using and the expiry date of the certificate. Chrome users may already start to see a yellow warning triangle across the padlock or even see a red ‘x’ and a red line through the letters ‘https’. It is not hard to see that this may stop many customers from proceeding resulting in lost business. At the very least, if customers do proceed, they are being ‘trained’ to ignore security warning signals.

So why not just replace all the certificates with ones using the SHA-2 algorithm? The problem here is that some old browsers don’t recognise SHA-2 so won’t show the web site as secure. For example, any users still using Windows XP, estimated by security vendor Kaspersky in August 2014 to be 16% of users, will have this problem if they have not applied Windows XP Service Pack 3 which supports SHA2 certificates.

So there is a business decision to be made around staying with SHA-1 and having some users not trust your web site or moving to SHA-2 where users may not be able to use it.

The PCI Security Standard Council has already stopped the use of SHA-1 in card readers and the latest version of PCI DSS, v3.1, prohibits the use of SSL from 30 June 2016, so organisations will need to upgrade to a suitable version of Transport Layer Security (TLS) to maintain compliance. Although the PCI DSS standard does not explicitly prohibit SHA-1 in TLS certificates, it does recommend that organisations refer to the NIST guidelines for TLS implementation as they upgrade their infrastructures from SSL to TLS. This NIST standard does not recommend the use of SHA-1 in certificates and it is therefore likely that such use in a PCI DSS environment would be thrown up as an error in security testing, resulting in a compliance failure. The use of SHA-1 for hashing credit card data in storage would also result in a PCI DSS compliance failure.

What can you do?

The first step in developing a migration plan should be to identify with your technical and security teams whether this is a problem for you and what the business and security impact will be of changing to SHA-2 as soon as possible or holding on to SHA-1 for as long as possible.

As part of this, it is important to:

  • conduct an inventory of your existing certificates. This can be done using automated tools to scan the infrastructure for certificates using SHA-1 use the results of the inventory from the step above to prioritise upgrades:
    • identify certificates for your most important sites and applications and begin upgrading to them as soon as possible
    • refer to Google’s advisory to determine when certificates will start to be affected (based on their expiry dates) and upgrade the ones which will be affected soonest.
  • implement a comprehensive program of testing to ensure that upgrading to SHA-2 does not impact compatibility. Older server platforms and clients may require patches and some may no longer be supported
  • to get the details right – ensure that you upgrade to the 256-bit version of SHA-2 and that the entire certificate chain is free of SHA-1
  • repeat automated scanning at regular intervals to ensure that new certificates using SHA-1 are not introduced.

An important thing to bear in mind is that you may still be required to retain the capability to support SHA-1 in your environment, for example, to verify old digital signatures. NIST continues to recommend that SHA-1 may be used in certain applications e.g. for generating and verifying hash-based message authentication codes (HMACs), key derivation functions (KDFs), and random bit/number generation. SHA-1 may also be used in more specific circumstances e.g. in SCADA control devices, which may not lend themselves to upgrades. It is therefore important to identify and prioritise applications that require upgrading and apply mitigating controls where necessary.

Contact us to find out more about implementing mitigation controls.

information_security