For now I'm not getting into the conceptual question of whether one centralized password trove is theoretically more vulnerable than the "distributed" approach of trying to manage this all on your own. In reality, I'm convinced that it's better to use a password manager, and safer than the alternative of trying to keep track of a whole list of passwords on your own. (For instance, you can read Last Pass's explanation of how it does encryption right on each user's computer, not at the central site, so that even someone who got the main controls wouldn't know your passwords.) The only password I keep in my mind is a very long password for Last Pass itself. It's so long that it could never be cracked by brute force, much as no one will win Warren Buffett's billion-dollar bet on the NCAA tournament. But it's very easy for me to remember, because it's a long passage I can reel off by heart.

-- I am using two-step sign-in processes for every system that allows them, and you should too. Gmail does this, and in fact pioneered this as a free feature for mass, non-commercial users. Last Pass also does so. How this works: In certain circumstances, logging in requires not simply your password but an extra, real-time code that is sent to or generated by your mobile phone or other device. What it means: For all practical purposes, someone cannot take over your account from afar. Since so many destructive scams and hacks are carried out remotely -- from Russia, China, West Africa, Israel, the Stans, you name it -- this is the easiest possible protection you can take against a very broad category of attack.

Two-step systems can be mildly inconvenient, but a lot of that has been buffed away. For instance, you can set Gmail so that it doesn't need the second password as long as you are using your own computer or phone. For more details, see this and this.

More as the story develops. The point for now: none of us can do anything about larger architectural questions of security, surveillance, vulnerability, and so on for the Internet. But along the spectrum of what that architecture makes possible, we can make ourselves less rather than more vulnerable. These steps will help.

Update: Via Bruce Schneier, it is very much worth checking out this test site, to see whether a site you deal with frequently has been repaired to avoid the SSL bug. For instance, here -- fortunately -- is what you would see for the Atlantic's site:

In theory, changing a password on a not-yet-fixed site could create new vulnerability, if a hacker has just decided to start watching it today. In practice, most of the people I have checked with say it's worth doing, because otherwise you're exposed to anything captured within the past two years. Then, when a site becomes safe -- as shown above -- it certainly makes sense to change the password. For further explanation, see this follow-on post.

Previous post Next post