Interesting blog post from Graham Cluley on LastPass’ support for using the Galaxy S5’s fingerprint reader as the key to your password vault. Since the S5’s fingerprint reader has been shown to be vulnerable to low sophistication fake fingerprint attacks, he wonders whether this (admittedly) very convenient feature is worth the risk. As a LastPass user, I don’t think I would base the security of the keys to my entire digital life on this particular piece of hardware. However, this does beg the question – is the low but non zero risk of someone getting hold of your phone and fingerprint exceed the risk of using the same damn password on every site you visit? LastPass also offers a mitigation for this scenario – it is possible to specifically permission which mobile devices can access your account. If you phone is lost or stolen, it is possible to revoke that permission (if you notice the loss or theft quickly enough). This is a risk calculation that users will have to make for themselves.
In this article over at Ars Technica, we get the scoop on Standford University’s new password policies which vary the requirements for password complexity (use of special characters, upper case, lower case, numbers, etc.) based on how long the user chooses to make their password. As the password chosen gets longer, the user is given more latitude to reduce the amount of complexity. I think that this is a great idea, providing users with choices in how their passwords are constructed while maintaining a level of security relevant to those choices. Unfortunately, this is not a policy which can be implemented off the shelf on today’s most ubiquitous operating systems – you would have to create some sort of a front end program to vet users’ password choices and then store them in the OS. Sounds like a great idea for an open source project to me.
Heartbleed strikes again… according to respected security consulting firm Mandiant, one of its corporate customers’ SSL VPN appliances was compromised by attackers using the Heartbleed vulnerability. The attackers were able to hijack logged in sessions and thus access the organization’s network. The key to detecting hijacked sessions is to look for log entries which show sessions switching between two different IP addresses at short intervals. Mandiant isn’t telling which vendor’s SSL VPN is vulnerable, but Cisco, Juniper, and the open source OpenVPN project have all issued security advisories related to Heartbleed. Infosec people should be checking for new VPN vendor patches and scanning logs for telltale IP address changes.
So, the risk management mavens for the City of Portland, Oregon have provided us all with an object lesson in how not to make risk based decisions. It seems that one of the local young rowdies had the audacity to urinate into one of the reservoirs supplying the city with drinking water. This particular reservoir contains 38 million gallons of water. Horrified at this sullying of the public water supply, the city fathers made the obvious decision – empty and refill the reservoir. I mean, it had pee in it! Never mind that the uncovered reservoir contains all sorts of other contaminants (animal urine and feces, dead birds, pollutants carried by rain, etc.) as a matter of course. Never mind that the concentration of urea caused by the wayward urinator would be around 3 parts per BILLLION – the EPA allows up to 10 parts per billion of arsenic in tap water, people. No, because this particular infintessimal contamination made the news, 38 million gallons of water is going to be dumped. As someone who has witnessed small children lugging jerry cans of water to their homes located miles away from the communal tap in Rwanda, this makes perfect sense to me.
It is this kind ridiculous approach to risk management that ensures that society will spend billions of dollars protecting itself from the wrong risks, and leave us vulnerable to the ones that really threaten us.
We need to get better at this, folks – science knows that people are bad at judging risk. That’s why we need to train professionals in all fields to use evidence based methods and processes which compensate for our built in handicap in this area. The basis of for good risk analysis is to train kids in critical thinking skills early and often throughout their education. Maybe, they’ll be better at this stuff than we are.
If you are using Google Chrome to surf the series of tubes we professionals cal the Interwebs, you need to take action to reduce the risk of getting scammed by compromised SSL certificates. According to this post over at Net craft…
However, most Google Chrome users are left in the dark, as Chrome performs neither type of check for non-EV certificates by default. Instead of conventional revocation checks, Google Chrome relies on an aggregated list of revocations, dubbed CRLSets, which are compiled by Google. The revocations from GlobalSign’s CRL have not yet appeared in Google’s CRLSets and hence Chrome users will not be warned if presented with a potentially compromised, but revoked, CloudFlare certificate.
The CRLSets deliberately do not cover all CRLs in an attempt to reduce the total size of the aggregated list. In effect, Google has traded the completeness of their revocation checking for a speed advantage over rival browsers as downloading CRLs or making OCSP requests imposes a performance penalty.
Google Chrome setting to enable revocation checking.
However, it is possible to configure Google Chrome to check for revocation. There is a checkbox in the Advanced settings menu to “Check for server certificate revocation”.
Think your sites are safe from Heartbleed related sploits? Not so fast, sunshine…
According to one pen tester, many of the tools which purport to detect servers vulnerable to the Heartbleed bug are buggy themselves, leading to false negative results, and in turn, a false sense of security allowing vulnerable sites to stay vulnerable. According to his testing, Qualys SSL Labs site is the most accurate “big name” source for checking your servers. He has also released a script called Cardiac Arrest, which he claims is more accurate than other Heartbleed tests. If you have already “cleared” your sites using the tools released right after the bug was announced, you might want to double check your results using one of these tools just to be sure.
It also turns out that certificate authorities are not the only ones profiting from Heartbleed. Because many, many organizations are busily revoking potentially compromised digital certificates, the certificate revocation lists (CRLs) which browsers download in order to avoid trusting these out of date certs have been ballooning in size, from just a few kilobytes to megabytes. These CRLs get downloaded from the CAs millions of times a day, leading to additional bandwidth charges from their ISPs. So now we have two sections of the Internet economy benefiting from Heartbleed.
Finally, the Canadians have arrested a teenaged hacker in connection with an attack on the Canadian Revenue Authority’s e-filing website which resulted in around 900 taxpayers’ personal information being disclosed.
Aaaand we now have our first confirmed breach of data tied to Heartbleed – the Canadian Revenue Authority has reported that the social insurance numbers of about 900 Canucks were downloaded by attackers using Heartbleed. Canada’s equivalent of the US IRS had shut down their e-filing website last week when the bug was announced.
Akamai (whose network carries almost a third of the Internet’s traffic) was also in the Heartbleed news this AM… it turns out that their patch to correct their servers’ vulnerability had a bug in it. They are revoking their certificates and issuing new ones in the wake of patching the patch.
Stay tuned… I am sure there is more to come