Don’t Mix Up SHA-1 Hashed Passwords with SHA-1 Signed Certificates

We really must get better at articulating technical risk. I read an article recently around a recent hack for SHA-1 hashed passwords, and…

Don’t Mix Up SHA-1 Hashed Passwords with SHA-1 Signed Certificates

We really must get better at articulating technical risk. I read an article recently around a recent hack for SHA-1 hashed passwords, and where this was then linked to the SHA-1 signature on a digital certificate. The risk on these is not quite the same. For SHA-1 hashed passwords, the actual method of SHA-1 doesn’t really have an weaknesses, but people select passwords which can be guessed from a dictionary, or even from brute force. For example, Hashcat knows that you put an uppercase letter first, and the number at the end, and that you use a ‘0’ instread of an ‘O’. It thus tries lots of different permutations, and will often get the right one. And so we now use slower hashing methods — such as Bcrypt — to slow the whole thing down. The risk of cracking SHA-1 hashed password is thus HIGH.

But what about validating things have not changed? Well for that we can use a hash for, and check the hash against the content. Unfortunately there’s only a finite number of hashes, so it will be possible to come up with the same hash for different content. For MD5 we had 128 bits, and so has 2¹²⁸ different hashes. Unfortunately, it doesn’t take too long to create a collision, and where we have different content producing the same hash. Recently, though, Mat McHugh showed that he could produce the same hash signature for different images, using hashclash, and for just 65 cents on the Amazon GPU Cloud, and took just 10 hours to process. He created these two images which generate the same hash signature (Figure 1). If we check the hash signatures we get:

C:\openssl>openssl md5 hash01.jpgMD5(hash01.jpg)= e06723d4961a0a3f950e7786f3766338
C:\openssl>openssl md5 hash02.jpgMD5(hash02.jpg)= e06723d4961a0a3f950e7786f3766338
Figure 1: Images

But, SHA-1 has a 160-bit hash length, and significantly stronger against a collision (in fact it is over 4 billion times stronger — 4,294,967,296 times stronger). And so with a lot of computing, the 160-bit collision is now marked as being practically possible, but would still require a massive amount of computing power. SHA-1 has thus been defined as a risk for the future, and the world has been told to deprecate it, before computing resources catch-up with it.

The signing of a hash on a digital certificate involves an intruder searching for a collision in the signed hash for a modified certificate — and still requires massive computing resources (especially to change bobco to eveco on the certificate). It has been shown that there is a risk on a SHA-1 signed hash, and where we can create a collision in the hash, and where we can create a valid signed hash for a different certificate. The risk of this is currently extremely low, but we know that things will develop, so SHA-1 hash signing is deprecated. The signing process of a certificate happens where the signer takes a hash of the generated certificate, and then takes their private key and encrypts this hash (such as with RSA). Whoever reads the certificate will then create their own hash, and then decrypt the signed hash with the public key of the signer. If they match, we know that the certificate has not been changed. But what does the certificate contain? Well, it’s the public key of the entity defining in the certificate.

Here’s is part of LinkedIn’s current certificate, with their public key (2K RSA), and with the signature algorithm (SHA256 with RSA) [here]:


Public Key Algorithm: rsaEncryption
RSA Public Key: (2048 bit)
Modulus (2048 bit):
00:a5:a5:2d:1c:96:55:a4:77:97:ad:fb:17:24:e2:
1a:d4:5e:10:1d:de:fc:6e:80:3d:1a:2f:bd:d0:f3:
b1:bc:55:a8:4c:9b:1e:f5:bb:79:71:d0:e2:2d:f6:
76:67:75:e5:c4:ef:b1:26:b6:8e:bf:02:c1:80:db:
ee:1d:34:c2:ee:01:78:3b:f5:2d:9e:b4:d3:34:a2:
6c:e9:d4:fc:00:03:fc:f2:97:bf:c0:89:d3:3d:4e:
8b:4f:3a:70:f7:90:10:6f:65:9f:f6:4d:98:2d:a7:
14:30:8f:35:0a:46:8a:f3:79:c1:12:58:b7:41:67:
1c:40:33:9a:9d:1a:d3:81:20:65:a3:fe:ee:61:d6:
48:60:c1:e1:93:53:41:a7:b0:50:e5:75:5d:5e:1c:
f5:e2:69:d3:1b:7b:f2:3d:0c:fc:bd:df:8f:4e:a0:
9a:97:4b:e3:18:30:3c:76:75:c9:af:55:fb:6f:4e:
dd:7a:87:9b:84:18:fe:c4:80:12:4c:07:95:0f:b6:
be:71:f2:94:0a:46:bf:3b:18:89:56:d1:29:f5:b3:
27:26:20:82:e0:cc:a2:c2:74:1d:5b:a5:0d:68:3a:
48:1d:6b:3d:7e:ac:73:75:7c:92:63:c8:98:87:6b:
65:44:80:f3:a1:4a:9d:81:eb:75:99:e3:0b:6a:c9:
de:cd
Exponent: 65537 (0x10001)
Signature Algorithm: sha256WithRSAEncryption
7a:64:90:2c:da:c2:b2:00:54:32:bf:57:b3:f1:e1:b5:bf:56:
61:f9:94:66:bb:2c:8f:9a:bb:8c:b4:82:06:a5:47:23:df:96:
99:e6:27:85:dd:bf:8b:fd:4e:4e:aa:eb:33:58:6b:f5:b7:b7:
3e:ce:bf:49:b6:73:90:e6:cc:33:ff:5f:a7:38:08:1b:87:ab:
ba:1e:16:8b:ce:44:09:11:9a:cc:da:94:90:11:da:73:28:a3:
9b:87:6b:d8:2c:d4:27:91:b2:58:c2:7a:2a:99:4d:38:1c:ec:
4d:3f:4f:78:d9:20:f2:2b:b0:73:a8:18:ec:82:f3:e0:60:14:
c3:b1:70:d2:c4:5d:72:a9:17:b1:fc:28:bd:47:49:a7:4f:4e:
8f:4f:04:2e:fa:ec:b2:1e:fb:f3:fc:47:c8:33:3c:78:bb:ed:
fb:d1:4a:c3:93:08:44:2c:c5:c7:1d:11:a0:74:8b:6b:1e:0d:
cf:ae:f8:50:5b:5f:dd:71:e4:30:dd:53:45:cc:e2:1b:45:62:
6e:66:58:3e:b3:3e:e1:05:28:c5:87:8e:ff:6d:ab:4a:5c:7b:
11:18:25:36:4c:e5:26:f1:96:76:49:37:4a:3b:1e:c1:a8:6e:
07:a3:fb:50:3c:09:fb:f3:af:a9:99:a6:69:9a:1c:ff:02:82:
da:65:13:b5

And intruder must try to change something in the certificate (such as the entity’s name) and then find the same hash that will work.

Conclusions

We need to be clear on risks, and articulate their scope. Cryptography has done a good job in migrating, before problems happen. The SHA-1 deprecation on certificates is our way of moving them off the stage, before they are thrown off the stage. Unfortunately PKI is one of the least understood areas of cybersecurity, but it is a fundamental building block. Please try and learn some of the most important elements, as any weaknesses could bring down your organisation.