Disheartened by the fallout from Heartbleed? You’re not alone. The tiny bug in the world’s most popular SSL library poked huge holes in the security wrapping our communications with all kinds of cloud-based websites, apps, and services — and the holes aren’t even all patched yet.
The Heartbleed bug allowed attackers to peel back the snoop-resistant lining of OpenSSL and peek at the communications between client and server. This gave hackers a look at things like passwords and session cookies, which are small pieces of data that the server sends you after you log in and your browser sends back every time you do something in order to prove it’s you. And if the bug affected a financial site, other sensitive information you were passing through the Net, like credit card or tax info, may have been seen.
How can the Internet best protect itself against catastrophic bugs like this? We have a few ideas.
Yes, you need safer passwords: Here’s how to make them
Okay, so better passwords wouldn’t prevent the next Heartbleed, but they may save you from being hacked someday. Many people are just awful at creating secure passwords.
You’ve heard it all before: don’t use “password1,” “password2,” etc. Most passwords don’t have enough of what’s called entropy—they are definitely not random and they will be guessed if an attacker ever gets the opportunity to make lots of guesses, either by hammering the service or (more likely) stealing the password hashes—mathematical derivations of the passwords that can be checked but not reversed back into the original password.
Whatever you do, don’t use the same password in more than one place.
Password-management software or services that use end-to-end encryption can also help. KeePass is a good example of the former; LastPass of the latter. Guard your email well, as it can be used to reset most of your passwords. And whatever you do, don’t use the same password in more than one place—you’re just asking for trouble.
Websites need to implement One-Time-Passwords
OTP stands for “one-time password,” and you may already use it if you’ve got a website/service set up that requires you to use Google Authenticator. Most of these authenticators (including Google’s) use an Internet standard called TOTP, or Time-based One-Time Password, which is described here.
What is TOTP? In a nutshell, the website you’re on generates a secret number, which is passed once to your authenticator program, typically through a QR code. In the time-based variation, a new six-digit number is generated from that secret number every 30 seconds. The website and client (your computer) don’t need to communicate again; numbers are simply displayed on your authenticator and you supply them to the website as requested in conjunction with your password, and you’re in. There’s also a variation that works by sending the same codes to you via a text message.
Advantages of TOTP: Even if Heartbleed or a similar bug were to result in the disclosure of both your password and the number on your authenticator, the website you’re interacting with has almost certainly already marked that number as used and it cannot be used again—and it will be invalid within 30 seconds anyway. If a website doesn’t already offer this service, it can probably do so relatively easily, and if you have virtually any smartphone, you can run an authenticator. It’s slightly inconvenient to consult your phone to log in, granted, but the security benefit for any service you care about make it worth it.
Risks of TOTP: Breaking into a server a different way could result in the disclosure of the secret number, enabling the attacker to create their own authenticator. But if you’re using TOTP in conjunction with a password that isn’t stored by the website—most good providers store a hash that is strongly resistant against reverse-engineering it—then between the two of them, your risk is greatly lowered.
The power of client certificates (and what they are)
You’ve probably never heard of client certificates, but they’ve actually been around a very long time (in Internet years, of course). The reason you probably haven’t heard of them is that they’re a chore to get. It’s far easier to just get users to pick a password, so only high-security sites tend to use certificates.
What is a client certificate? Client certificates prove you are the person you claim you are. All you have to do is install it (and one works across many sites) in your browser, then choose to use it when a site wants you to authenticate. These certificates are a close cousin of the SSL certificates websites use to identify themselves to your computer.
The most effective way a website can protect your data is to never be in possession of it in the first place.
Advantages of client certificates: No matter how many sites you sign in to with a client certificate, the power of math is on your side; nobody will be able to use that same certificate to pretend to be you, even if they observe your session.
Risks of client certificates: The primary risk of a client certificate is that someone may break into your computer and steal it, but there are mitigations for that risk. Another potential issue is that typical client certificates carry some identity information you may not wish to disclose to every site you use. Although client certificates have been around forever, and working support exists in Web server software, there is still a lot of work to do on both service providers’ and browsers’ sides to make them work well. Because they’re used so rarely, they get little development attention.
Most importantly: End-to-end encryption
The most effective way a website can protect your data is to never be in possession of it in the first place — at least, not a version it can read. If a website can read your data, an attacker with sufficient access can read your data. This is why we like end-to-end encryption (E2EE).
What is end-to-end encryption? This means that you encrypt the data on your end, and it stays encrypted until it reaches the person you are intending it for, or it returns to you.
Advantages of E2EE: End-to-end encryption is implemented in a few services already, like online backup services. There are also weaker versions of it in some messaging services, especially those that cropped up after the Snowden revelations. It is hard for websites to do end-to-end encryption, though, for two reasons: they might need to see your data to provide their service, and Web browsers are terrible at performing E2EE. But in the age of the smartphone app, end-to-end encryption is something that can and should be done more often. Most apps aren’t using E2EE today, but we hope we’ll see more of it going forward. If your apps aren’t using E2EE for your sensitive data, you should complain.
Risks of E2EE: For end-to-end encryption to work, it must be done across the board—if an app or website only does it halfheartedly, the whole house of cards may collapse. One piece of unencrypted data can sometimes be used to gain access to the rest. Security is a weakest-link game; only one link in the chain must fail to break it.
So, now what?
Obviously, there isn’t a lot that you, as a user, can control. You’ll be lucky to find a service that uses one-time passwords with an authenticator. But you should definitely talk to the websites and apps you use and let them know that you realize bugs in software happen, and you think they should take security more seriously and not simply rely on passwords.
If more of the Net uses these these advanced security methods, maybe next time there’s a Heartbleed-scale software catastrophe—and there will be, eventually—we won’t have to panic so much.
[Image courtesy of scyther5/Shutterstock]
