There are a huge number of news items, tweets and posts running around the Internet at the moment. I don’t pretend to know the details about Heartbleed, but I do not some of the expert opinion offered just adds to the general public’s confusion, and does not really help matters.
Some commentators observe Heartbleed could – emphasise – could have led to a Password compromise – no evidence is given of this having yet occurred (but you can be sure people are now trying…). Thus we now have many commentators calling for all users to change all passwords.
Whoa! Just hold on a minute, and check reasons to slow down a bit – Graham Cluley offers a good commentary.
Two Step Verification
Even if this were right, is it the best advice we can give? We have long known passwords are dead as a viable security technology. Rather than tell everyone to change their passwords – why not suggest upgrading to two-step verification or two-factor authentication instead? It’s almost as easy, and takes just about as long as changing your password to set up on most sites.
It may not 100% solve the issue, but it significantly reduces the issue.
If thinking of acting after the Heartbleed incidents, don’t just punt the problem until the next compromise, do something different…
- Wait a bit, until the patches are in place
- Don’t just change your passwords, upgrade to two-step verification or two-factor authentication
Once Upon a Camayoc 
Randall Munroe has just posted an xkcd cartoon which I think does a rather good job of explaining Heartbleed: http://www.xkcd.com/1354/ .
While Heartbleed goes to show how reasonably straightforward bugs can go apparently unnoticed in security-focussed code for some time, I’m pretty surprised that static code analysis tools didn’t pick this one up earlier. As well as the OpenSSL code itself (now fixed), I’d say code analysis tools should be checked-out regarding how this was missed.
On the “change all your passwords” advice, I admit I’m sitting on the fence just now; Mashable is producing a list of common services and their vulnerability status at http://mashable.com/2014/04/09/heartbleed-bug-websites-affected/ , and it’s apparent to me that users would only need to change some passwords, probably not all. While it’ll increase traffic for a while, I’d suggest users have a look at one of the Heartbleed checkers which are springing up (I’ve been using http://filippo.io/Heartbleed/ ) to see which other platforms they use, need looking at. For example, I found an old Linux VM on my estate which is vulnerable, but my Solaris instances are all fine.
I wouldn’t want to be an enterprise sysadmin this week, given the number of OpenSSL instances which are likely to need patching – and I agree it’s likely to take a few days for the fix to ripple across everyone’s server estate. While I don’t have an opinion as to whether a user should change their passwords immediately, they should definitely check whether a site which has been shown to be vulnerable has been patched, before changing their password to a new one they want to use long-term.
2FA’s a possible answer, of course – but it doesn’t work well for some services, and last I looked, it was a long way from straightforward for service providers to integrate. Also, 2FA which uses SMS requires a ‘phone number to send one-time passwords to – and that opens the need for discussion and policy around user PII. It’s a problem I still don’t see a single elegant answer to, especially when legal considerations are taken into account – and that’s the most likely reason why passwords are still around…
LikeLike
As a little follow-on to my thought about static analysis tools, Coverity have produced a thought-provoking article about finding Heartbleed and other bugs like it; it also has some further useful links. It’s worth a read; see http://security.coverity.com/blog/2014/Apr/on-detecting-heartbleed-with-static-analysis.html .
“A friend who would know” has told me that none of the static analysis tools caught Heartbleed before it was discovered manually in April, and reading between the lines of the Coverity article, it appears to be early days when it comes to developing analysis techniques which will pick such issues up – in C source, anyway. There’s been various opinion-pieces posted about how Heartbleed would have been picked up much more easily if OpenSSL had been written in another language (C++ seems to be the suggestion most frequently offered), but not being a software engineer, I’m not in a position to comment…
LikeLike
Also, it appears that the Heartbleed check script at filippio.io , like many others released very promptly following Heartbleed’s announcement, isn’t wholly reliable when it comes to identifying vulnerable systems – it’s possible to get false negatives. Rather more comprehensive, it appears, is the “Cardiac Arrest” script, described at http://www.hut3.net/blog/cns—networks-security/2014/04/14/bugs-in-heartbleed-detection-scripts- .
LikeLike