Heartbleed Bug: Which Websites Recommend Changing Passwords?

Well it is tough to argue with the knowledge of the Internet... I guess I better get back to my day job since it seems I am way behind!

Dave

I guess I was replying to your statement that 95% are new features and the URL was a list of security vulnerabilites (openssl's words, not mine.) Vulnerabilities are holes in security, not just run of the mill bugs.

With security it's often quite difficult to tell if a given vulnerability might apply to features you're using in a product. In order to make that decision, you have to research the specifics of the issue and have a pretty intimate understanding of what it refers to. It's very challenging even for the most seasoned sysadmins.

For example, CVE-2014-0076 (CVE stands for Common Vulnerabilities and Exposures) is listed as "Fix for the attack described in the paper "Recovering OpenSSL ECDSA Nonces Using the FLUSH+RELOAD Cache Side-channel Attack" Reported by Yuval Yarom and Naomi Benger." The listing in the NVD isn't that much clearer: "The Montgomery ladder implementation in OpenSSL through 1.0.0l does not ensure that certain swap operations have a constant-time behavior, which makes it easier for local users to obtain ECDSA nonces via a FLUSH+RELOAD cache side-channel attack."

Just at first read it's pretty difficult to say whether or not this is something I would care about. Further research would help determine the risk, often defined as "Risk = Threat x Vulnerability x Impact" and then the business cost has to be weighed as well.

You would have to go through the same process for each of the 9 security vulnerabilities that were fixed in the past 2 years to determine if you needed to upgrade or not. And then all your systems would have to be thoroughly tested to make sure the ugprade doesn't break anything.

But I still believe my original statement was accurate: "If you didn't update openssl in more than 2 years you were missing many vulnerability fixes."

bwanshoom wrote:

I based my response on the list of vulnerabilties from openssl listed here. It appears there were at least 9 security vulnerabilities resolved in the past 2 years not including Heartbleed. While what you say is true for most software, openssl is pretty much all security or security-related.

Since we are looking at the same list it is easy to see where we disagree. I see a difference between "security" and "vulnerability", you lump them together. Being exposed to a DoS or a crash is a vulnerability, peeking into 64K of memory is a security hole. Much of the software "you don't see" is never exposed to situations where it would be vulnerable to a DoS or client/server crash so there is no concern for preventing it. If it was the fixes would be implemented.

Dave

magicbus wrote:

bwanshoom wrote:
... If you didn't update openssl in more than 2 years you were missing many vulnerability fixes. Security software updates are generally pretty important.

You might think that but OpenSSL isn't Windows or OSX. I would venture a ballpark guess that 95+ percent of the changes are additional features and 99% of the remaining 5% concern specific features and their usage. The remaining .05% are fixes like correcting bugs introduced by the addition of a new feature (think heartbleed bug here).

The cost to properly test software is high and it is cheaper and safer to analyze the impact of not updating than it is to blindly update, test, and release.

Dave

I based my response on the list of vulnerabilties from openssl listed here. It appears there were at least 9 security vulnerabilities resolved in the past 2 years not including Heartbleed. While what you say is true for most software, openssl is pretty much all security or security-related.

bwanshoom wrote:
... If you didn't update openssl in more than 2 years you were missing many vulnerability fixes. Security software updates are generally pretty important.

You might think that but OpenSSL isn't Windows or OSX. I would venture a ballpark guess that 95+ percent of the changes are additional features and 99% of the remaining 5% concern specific features and their usage. The remaining .05% are fixes like correcting bugs introduced by the addition of a new feature (think heartbleed bug here).

The cost to properly test software is high and it is cheaper and safer to analyze the impact of not updating than it is to blindly update, test, and release.

Dave

I use the Google Authenticator (which is a part of the EPEL library for RedHat) to log onto my own remote machines. Same with Gmail and Amazon's AWS.

For PayPal and eBay, I have both SMS authentication, and a keyfob. That way, if I lose my phone, I'm not utterly hosed.

For a couple games, I use a phone app.

For my virtualization host, I use IP address protection, where it will send E-mail to my gmail account (protected by two factor authentication) if I try to log on from a new IP range.

None of this is 100%, but it means an attacker has to do more than just yank a password out of RAM.

One nice thing about Android is that the apps that give the validation codes can be easily backed up encrypted using Titanium Backup, and stored on a cloud provider. That way, if the phone gets lost, I can get another Android phone, restore the data, and be back in business.

I actually use Google Voice for phone authentications. Except for Google services.

Reddog1 wrote:
How do you use the phone for authentication?

Wayne

There are a few ways. One is the site sends you an SMS message with a code that you enter. Another is to install an app that produces a number code every minute or so that you enter when prompted, similar to an RSA token. Twitter uses the former method. Google uses the latter method as do a few other sites that leverage Google's app such as Amazon Web Services and LastPass, if so configured.

How do you use the phone for authentication?

Wayne

It might be wise to see about two factor authentication, assuming one has a phone that isn't going to be going away anytime soon. This way, if a bad guy snarfs a password, it will still keep the account secure. I do this with a number of websites (Google, Amazon, PayPal, eBay), and so far, so good. Nothing is perfect, but it is a notch above just one password keeping the bad guys at bay.