If you’ve been following any infosec community news recenty, you may have seen that the SHA1 hash has taken yet another blow. Shoutout to Dan Goodin at Ars Technica for an easy-to-follow explanation of what just happened here. This isn’t the first time SHA1 has had a bad day either, as early as 2005 different levels of vulnerabilities had been discovered. In 2017, with announcement of the first public collision, it should have been retired for good. Calculable collision times of thousands of years of computing time doesn’t scare anyone anymore. We are in an age of pay-as-you-go cloud computing services. I can call upon the mighty AWS gods to give me thousands of GPUs upon which I can calculate my first SHA1 collision on a stolen credit card before the charges are even disputed! — The SHAsome Collisioninator (insert Heinz Doofenshmirtz laugh here)
Agent P is not going to save the day. We don’t even have an O.W.C.A – but we do have OWASP, which has seemingly been preaching on deaf ears calling out against SHA1 since at least 2007. So why is this still a big deal? It’s part of a bigger problem, one which we have become complacent with, in fact, we have come to expect it — Compatibility.
I’m not a Cryptography Expert
But I do have an Idea. If you can’t update it, wrap it. Stop choosing the lowest denominator so you can get by with what you have. If you’re worried about your clients not being able to connect because they have some legacy equipment just say “I’m sorry, but we won’t reduce our security for your comfort”. This falls under the logic of “… the needs of the many outweigh the needs of the few”. I put before you the case of a national financial institution I, very briefly, had an account with. They had customer password requirements of 8-12 characters, must have at least one capital letter and one number. NO SPECIAL CHARACTERS.
First of all…. Ever hear of the NIST password guidelines? Let me recount what should be considered the bare minimum
8 Character minimum (it had better look like a keyboard smash, but that’s my opinion)
At least 64 Character maximum (notice that’s not a hard limit)
Normalized Unicode character acceptance (NFKC/NFKD)
No dictionary words (not to exclude passphrases)
No repetitive or sequential key sequences (‘abcdefghijkjkjkjkjkjkjkjk’)
Restrict context-specific words (your google password can’t be ‘google2k’)
No composition rules (mixing numbers and capitalization etc.)
No expiration date (Take a bow and exit gracefully “your password will expire” notifications, nobody wants to make a scene, just get out, you’re old)
Now honestly, I don’t see why the maximum should be anything more than a recommendation – If I want to spend the next 6 minutes calculating the salted hash of my password on my own device for entropy’s sake, that should be my prerogative, correct? There’s no possible legitimate reason for my password to be sent across the internet and stored somewhere unhashed, correct? So honestly, lets keep the minimum, but shouldn’t my password, or better, passphrase be whatever I can remember, no matter how long it is? NIST seems to agree for the most part.
Oh, but our blahblahblah system from 1990 that stores your mailing address only accepts up to 12 characters and we can’t afford to upgrade it (yes you can).
Alright – Wrap it. Yup, put up some little proxy that takes the MD5 that sweet sweet salted SHA512 and attempts a base64 conversion to ascii values which becomes the internal password for that ancient system that needs to be kept around. That system can now only be accessed by the proxy and poof, your old thing feels like a new thing (Please upgrade it ASAP).
Back to SHA1
Do not accept it. It’s dead. We keep killing it, but it’s dead. By all means, it should not be enabled by default if you still want to ship with compatibility. Should we move to SHA256? Yeah, sure, or SHA512 because why not? It’s only a matter of time before it’s 10 cents a petaflop, that should buy us some time, but don’t let the algorithm become so intrinsic to the design that you can’t walk away from it when we randomly have a breakthrough in quantum computing and a cellphone can calculate a collision before the second stage of a Diffie-Hellman key exchange. After all, security based on a matter of time is simply security through obscurity isn’t it?
Bottom line, security needs to be intrinsic, and hot swappable because “all of this has happened before, and all of this will happen again.”