Number:IRCNE2014062223
Date: 2014-06-20
According to “zdnet”, no doubt there are still many vulnerable web sites and many more users who never changed their passwords from vulnerable web sites, and the consequences haven't been catastrophic.
The theory was that since so many sites were vulnerable for so long, you should (once the site patched OpenSSL) change your password on all of them. It's unlikely that a lot of sites were so-compromised and mined.
Few people would have bothered even if it were easy, but the fact remains that if you were following best practices with your passwords — making them complex and long and not reusing them, and using a password manager to make that all practical — changing all your potentially-vulnerable passwords is a daunting task. It has to be a manual, one site at a time thing.
When the Heartbleed smoke cleared I asked a couple of vendors about the problem and proposed a solution: a standard web API for changing site password, probably for use by password managers. The information you need to change a password — basically the URL, the userID and the old password — should all be accessible to the password manager.
Some of the potential problems, such as CAPTCHAs, are obvious, but I'd still think there is a way around them, if only through an authorization email to the account on record. Even if that email required you to follow a link and fill out a CAPTCHA it would still be far more automated for the user than if the whole process were manual.
But the vendors told me that they didn't think it could be done reliably. I still don't understand the problem, but they know a lot more about these things than I do, so I'm sure they're right. It's a damn shame.
Automation could also be useful in non-crisis situations. One of those best practices for passwords that nobody follows is to change your passwords periodically. A good password manager could track password age and, at a predetermined interval, offer to change site passwords. If it were an automatic process I would do it.
One person suggested to me that I was looking at it the wrong way, and that the answer to the password problem was OAuth. The official OAuth site defines it as an "authorization framework" which " enables a third-party application to obtain limited access to an HTTP service." This is like when a site offers to let you log in with your Facebook or Google account.
Even the user experience with OAuth can be confusing in my experience. I'm also uncomfortable using one of these big services as my identity on some of these other services. I like to maintain the maximum flexibility on them.
The biggest reason nothing has been done about the problem is that it's way down the list of things we need to do in order to make users more secure.
Very few users have proper password practices and industry attention is certainly best-directed to addressing that. Even so, I take the fact that the problem is so difficult as a sign of potential trouble in the future.
- 4