For those interested, starting a new thread:

http://www.theatlantic.com/technolog...ed-bug/360395/

A PSA to everybody to change their passwords on websites. Even though some of them is not affected by the bug, it's good habit to change password once in a while.

Is there a way to tell awardwallet to suspend updating my accounts (until all/most the servers have been patched and received new certificates)?

This is incomplete advice. The more important concept is to have different passwords on every website, and to use two-factor authentication whenever possible. Here's a list of vulnerable sites.

Changing passwords makes sense and is a good habit to maintain, but does it make sense to change your password on a website that's still potentially compromised? A better route might be to wait for an announcement for the site stating that issues have been patched or to proactively check on the status of a site before changing your password.

As my earlier link suggested, Bob is totally right on. Never use same password for different site and whenever possible, go with two factor authentication.

Here's another way to check if site compromised: http://filippo.io/Heartbleed/. If you find it useful, send a small donation to the creator [Full disclosure: no relationship with creator].

Indeed. Wait, then change it.

This is LastPass recommendation: http://lifehacker.com/lastpass-now-t...swo-1561522244

Don't go changing your passwords right now at all, that's the worst thing one could do. The passwords ON a site are not currently at risk. It's the passwords and information currently IN TRANSIT that is the issue. If you go and change your password on a site that is currently not secure, you're creating the risk in that scenario. A lot of this has been updated already for several months by most critical sites. I would hope that many would continue to finish the updates soon now.

+1. Changing your password now is about the riskiest thing you can do. Better advice is to not visit any sensitive SSL sites (like your bank) for a few days (or weeks) until they patch their OpenSSL.

LastPass and NoScript. Don't surf the web without them.

Most of the banks really don't look like they were vulnerable in the first place, at least the bigger ones.

I've got to be honest, I think this particular bug is being heralded as far more of an issue than it really is. Yeah, the whole has been around for a fair amount of time, but there's not really any evidence that anyone knew about, let alone was exploiting it before very recently. I honestly think if it had been a problem before, we'd have heard about it long before. Heck, even though openssl 1.0 has been out for that year and a half, it doesn't appear that everyone really jumped on the bandwagon and updated to it (out of curiosity, I checked a web hosting provider I use for a site, and it was using a version of .9.8).

Now, obviously, now that the issue is a known issue sites have to fix that problem, and ironically, things are probably at their most vulnerable during this time period with places that are slow to fix things. But I'm not overly convinced that the level of panic that this seems to have created is really warranted. Obviously I'm not saying that it's necessarily a bad idea to change passwords, but I just don't really believe that there's any evidence that the odds are very high that your password would have been compromised.

Anyhow, that's just my personal opinion. I'd like to think that it's a reasonably informed opinion, but take it with the proverbial grain of salt.

Delightful Xkcd cartoon explaining the bug:

http://xkcd.com/1354

> there's not really any evidence that anyone knew about, let alone was
> exploiting it before very recently.

Few sites keep the voluminous logs required to determine if they've been
subjected to HeartBleed intrusion.

EFF is reporting that HeartBleed's first notice/exploit was logged in November
2013, from source IPs: 193.104.110.12 and 193.104.110.20 ... both of which
seem to be members of a larger botnet.

What HeartBleed has done is highlight:

- Too few browsers are checking & obeying certificate revocation.
You should check ALL of your browsers. I suggest using:
https://revoked.grc.com/

--- If your browser delivers GRC's explanation page, your browser
--- is not correctly handling revocation.

- Too few Certificate Authorities are following the rules re: certificate
revocation. By contract; a certificate authority is obligated to revoke
certificates within 24 hours if there is evidence of a key compromise.

--- A private key is considered to be compromised if its value has been
--- disclosed;
--- *OR*
--- If there exists a practical technique by which an unauthorized
--- person may discover its value (private key). This did not happen
--- and is not yet happening. There should have been ~500k
--- revocations by now ... and we've seen only a trickle.

- IMHO; the certificate revocation infrastructure has failed us. It needs
to be re-architected. I suggest starting with something more in the
spirit of DNSsec.

Certificate revocations don't work. http://arstechnica.com/security/2014...rdist-theater/

There's no point in revoking a certificate if the system is still compromised.