How Twitter can permanently end password breaches

by Steve Kirsch, OneID
February 7, 2013

The advice Twitter gave to their users (to change their passwords and use long passwords with special characters, and use different passwords on every website), while appropriate under the circumstances, won’t prevent the exact same problem from happening again...and again...and again.

This is not the first time Twitter has been breached. Each time the advice given to users is the same and each time it happens again. Twitter follows industry best practices and has assembled a top-notch security team. If it can happen at Twitter repeatedly, it can happen to any site. The US Federal Reserve was also just broken into an passwords were stolen. RSA Security was broken into and the secret key used for all the RSA SecurID tokens was stolen.

What can and should sites be doing differently to prevent future breaches? Is it even possible? Surprisingly, the answer is yes. These breaches are 100% preventable if users do one simple thing that makes their user experience easier.

Many people have suggested that Twitter should add two-factor authentication (2FA). Although it sounds “secure,” really won’t prevent future password compromises for several reasons:

1. It is too cumbersome for users because it makes logins which are already hard even harder with no user benefit. 2FA compliance is well under 1% in practice. For example, at Google which for many users contains much high valued assets that tweets, the 2FA compliance is well under 1%. With <<1% adoption, it is almost like doing nothing. You can get higher adoption if you force people to use it, but that will cause a user revolt. It will never happen.
2. Even if a miracle happened and 2FA was fully adopted by 100% of Twitter users, the attackers will simply also steal the 2FA secrets as well. For example, last year Activision Blizzard had an attack where player names, passwords, personal security questions, and mobile and dial-in authentication information were all compromised.
3. Adding 2FA doesn't suddenly "lock down" the password file and prevent it from being stolen. It will still be gone. And most users use the same or similar password on other sites. So the password file breach still happens and users are still advised to have to change their password(s). 2FA or no 2FA, the results are the same.

Adding 2FA also creates many additional problems including:

1. Users fundamentally want to get rid of usernames and passwords, not make the process harder by introducing even more complexity into the authentication process. Imposing 2FA adds yet another thing that can go wrong. Users view security as something the service provider should be responsible for, not the user. Even one of the most respected system administrators I know wrote me a note recently, "I use 2FA for Google, and I hate it."
2. Adding 2FA to a site may have the benefit of making users “feel” like they are more secure, but the reality is that the same set of attacks aimed either at the user’s device or the service provider can still compromise an account at either end. So the user is doing a lot of extra work for marginal benefit. The marginal benefit is this: if the attacker steals the password file but doesn't also steal the 2FA file of shared secrets or the file containing the shared secret cookie values of the devices that are trusted, then the attacker won't be able to log into that person's Twitter account unless the attacker controls the person's machine. On the other hand, the reason 2FA users are spared right now from attack is that 99%+ of the usernames don't have 2FA. So it's simply a waste of time to get the additional information. If more users adopted 2FA, the attackers will make more of an effort to steal the 2FA or trusted device information, rather than just the passwords. So right now, there is a marginal benefit if you are concerned about your Twitter account being hacked, but it is limited to the few people who use 2FA and it will likely go away if 2FA became more popular. Your password is still compromised no matter what.
3. Most all 2FA implementations don’t sign the request so the user really never knows what he is approving.(this is more of a problem if 2FA is being used for more than login, e.g., to approve transactions).
4. The service provider may only require the 2FA on logins only for untrusted devices rather than all logins (e.g., Google). Therefore, instead of using the attackers machine (which would force a 2FA), the attacker simply uses the victims machine.
5. The service provider may allow you to easily disable 2FA on any trusted device without any 2FA confirmation (e.g., Google).
6. If you log into a machine with malware with 2FA, malware on the machine can still compromise your identity and issue transactions without your consent
7. Most 2FA implementations don’t digitally sign the transactions so MITB attacks, keylogging, and phishing attacks (phishing your username, password and OTP number) will work.
8. If you are using TOTP (time-based One-Time Passwords), you’ll have a limited amount of time to transcribe the number to the computer
9. Not all apps support 2FA. So at Google for example, you need to create special app-specific passwords further adding to the complexity.
10. Each service provider offers a different set of 2FA methods and setups and rules and backup codes. It is mind boggling.
11. It is recommended you keep a set of backup codes with you at all time. A separate set of codes for each website with 2FA. You thought passwords were bad? This is worse.
12. If your Google account is managed by your company, your ability to add 2FA may not even appear on your settings.
13. Adds friction to the account signup process at a website.
14. If you lose your authenticator, you have to re-provision it at all the sites you used it at (which could be hundreds of sites if all sites took this approach). And you’ll have to authenticate using other techniques because your normal authentication isn’t available.
15. You may have to remember which authenticator you used with each site, e.g., if you have two or more TOTP authenticator apps, the site generally won’t give you a clue as to which app you used for that site. Use the wrong app, and it won’t work.
16. If the 2FA is SMS based, it means that the user’s phone number must be disclosed which means that even more information can be compromised on a break-in
17. If you lose your cell phone, each site with 2FA has a different recovery technique.
18. There is no apparent backup mechanism for the codes in Google Authenticator and other soft token generators. If they are encrypted securely in the keychain, if you upgrade the hardware or lose your phone, all of your codes are lost. If they aren’t encrypted securely, then either Apple or someone who breaks into your backups can learn your codes. Either way, it is a big problem if 2FA becomes popular.

The only real way to prevent this from happening again is for Twitter to replace the use of shared secrets (where the user shares a “secret” such as a password with a third party such as Twitter) with identity that is based on digital signatures. This can be done gradually by encouraging users to switch to this login method and invalidate their password login. This means that there are no longer shared secrets stored at Twitter for those users. A private key on the user’s device generates the signature and a public key on the Twitter website verifies (but cannot generate) the signature. If the authentication database is breached at Twitter, the data is useless to an attacker because the public keys stored in that file can only be used to verify that the digital signature is correct, not to generate a digital signature. The public key cannot be used to log into Twitter, or to break into other websites. Conversely, break-ins at other websites will not enable an attacker to log into Twitter.

Benefits to Twitter include:

• Immunity from future break-ins
• It makes Twitter a much less attractive target for attacks when the attacker knows there is little of value in the event of a successful break-in. Even attackers have to prioritize their time, so Twitter will drop lower on the priority list. Fewer attackers and less valuable data means greater security for Twitter’s users.
• Relieving Twitter from having to become an expert in identity and security and account recovery so they can focus on their core competencies
• Alignment with where identity is going. The future of identity is the use of digital signatures, architectures which preserve privacy and provide increased security without compromising ease of use, and elimination of the use of passwords (when used as a shared secret). For example, an NSTIC requirement is the elimination of passwords as shared secrets.

Benefits to users include:

• Easier login to Twitter (no Twitter-specific username or password to remember)
• Enhanced security options (such as digitally signed out-of-band authentication or authorization) equivalent to or better than two-factor authentication, but without any of the ease of use issues that would impede adoption
• Users will never again have to change their password if there is a break in at Twitter or at any other website
• The ability to use their digital identity at other sites without having to go through cumbersome registration processes (including picking and remembering unique usernames, passwords, 2FA methods, initializing 2FA tokens, etc)
• Freedom from having to use a social identity to login (half of users don’t use social logins due to privacy concerns)
• Improved privacy (a proper public key identity system uses unique public keys at each website)
• A single password to remember that cannot be phished or keylogged . That one password can be used on all websites that support the same digital identity system without any security risk. Unlike passwords used in a shared secret authentication system, passwords used in digital signature-based identity systems are not a shared secret. The password never leaves the user's devices and is not grindable (so you cannot steal any data and compute the password even with an infinite amount of computer power at your disposal).
• OneID is an identity system designed from the ground up around digital signatures that meets the requirements stated above (and more). It is very consumer friendly, and completely hides the complexity of the key management from the user. OneID does not have usernames, and defining a password is optional. It the only truly trustable federated identity on the Internet today. If a user opts in for a OneID and removes their password, they are 100% safe from future password file breaches at Twitter or any other site they do this on.

So a site has a choice:

1. Continue doing the same things they are now and risk repeated breaches.
2. Implement 2FA and still risk repeated breaches even for the 1% who opt in
3. Implement OneID and end the problem once and for all for users who opt in

Additional commentary

Excerpted from my remarks on the discussion of this article on LinkedIn

Twitter could use an HSM to encrypt the hashed passwords. That would add a layer of security in that the HSM-encrypted salted hashed passwords would then be, for all practical purposes, impossible to breach if you *only* grabbed that password file. Twitter could do a password verification by retrieving the encrypted hashed+salted pwd from their password database, use the HSM to decrypt it, and comparing that to the hashed+salted input from the user. This just changes how Twitter would be attacked and makes a mass compromise of password data unlikely. This would force the attacker to either utilize the HSM himself, or watch the passwords as they are coming into Twitter, or watch the passwords after they've been decrypted by the HSM. My point is that using shared secrets is always a disaster waiting to happen as Twitter has repeatedly shown. Those can be passwords, 2FA techniques that rely on shared secrets (such as TOTP), or whatever. It doesn't matter. It is the shared secrets that have to go. The elimination of shared secrets is what all identity professionals should be calling for in the Twitter case, and not for the introduction of 2FA.

I love passwords, but only if they are used PROPERLY. Using passwords as a shared secret for authentication should never be done. We use passwords in OneID. But they are never shared secrets. They are used in combination with a local salt on the user's devices to create a private signature key. This means you can't grind the password on the server or on the client, even with infinite computing resources. So if you crack into my devices or you crack into OneID servers, you can never, ever, determine that my password is "x" even with INFINITE computing resources. And my password is really one character "x." Even if I told you it is one character, it is not grindable. So that is much stronger than the HSM case above where the passwords are crackable at the Twitter end with sufficiently large computing resources (I fully admit that for an HSM it would require huge resources from any practical point of view).

My post addressed the best way for Twitter to respond to password breaches. Mixes are good. But methods relying on shared secrets (such as a shared password or a password that is hashed or even encrypted by a symmetric method such as AES-256) are never as strong as asymmetric crypto methods. Allowing authentication into Twitter using only shared secrets (such as password only, or password + TOTP) is a really bad idea as we've repeatedly seen.

 PKI isn't the answer. PKI isn't end-to-end secure. Remember DigiNotar? Our security guys at OneID stay away from PKI like the plague. It's all about end-to-end security.

You should always assume that attackers have malware on all your servers and are watching everything that happens on your servers and sending reports back to the mothership. Keeping out all malware is as realistic as saying you can keep ants out of your home. If you really want to be secure, make sure your identity system can withstand that kind of attack. The secret is simple: the identity system must require at least one digital signature (more are better) and that digital signature better be generated on the user's device(s) and verified by the RP itself, and not by an IdP in the middle. OneID was designed from scratch to do exactly this; it is totally immune to these sorts of attacks. You could also accomplish this using PIV or CAC cards that require a local PIN code, but cert management is very difficult.

The point is if you want to be secure, you should be using digital signatures in a way that is both end-to-end secure and also very usable by users. Passwords are fine to use, but only if they are used to decrypt local signature keys, and never as shared secrets. These were the some of the core principles that OneID was built upon, and that any trustable IdP must exhibit as well.

OneID documentation guide