A few days ago, Twitter asked all of its users to change their passwords. The reason they did that was that they found a bug in their system that made an internal log file store passwords in an unencrypted form. That means a hacker who got hold of that file would know everyone’s passwords.
That’s pretty bad, particularly with all of the Twitter hacking and spoofing that’s been going happening lately, but it’s even worse when you consider how people use passwords. Remembering a good password is hard. For example, the password 7wpwfmkMWf is strong but it’s very hard to remember.
That means many people either use easy to guess passwords such as names or birthdates, or they use one or two stronger passwords for multiple systems. What a hacker might do is steal your Twitter password and then try to use it on other sites such as Gmail, Hotmail, Apple, PayPal, Capital One, Citibank, and others.
Having someone steal your Twitter password is annoying. Having them use that password to plunder your online bank account would be catastrophic!
All of this raises a couple of important questions such as:
- Why were the Twitter passwords stored in an unencrypted form?
- Why didn’t Twitter expire all of the passwords?
- How can you use multiple strong passwords safely?
Why were the Twitter passwords stored in an unencrypted form?
The short answer is, “They should not have been.” This is basic cryptography. You should never store a password in unencrypted form. Never, ever store unencrypted passwords in a file even if you know that the file is on a secure system. Over the last few years, literally millions of passwords have been compromised because the files that a company thought were secure were lost or stolen.
Ideally, you shouldn’t even have an unencrypted password sitting inside the program for longer than absolutely necessary. A program should take the user’s password, encrypt it, see if it matches a stored encrypted version of the password, and then clear the memory holding the unencrypted version.
Just a few days before the Twitter announcement, I posted the example Make the user enter a password to use a program in C#, which uses that approach. Download it to see the details. It isn’t hard.
Another approach that you can use in C# is to try to use the password entered by the user to open a database or other tool that has its own password system. Then you can piggyback on that system’s password system. I’ll post an example that does this in the next few days, too.
Why didn’t Twitter expire all of the passwords?
Normally when a web site thinks passwords may be vulnerable, it expires all of the users’ passwords so they must reset them the next time they log in. This is fairly common and users don’t mind too much because (1) it’s not terribly hard and (2) they know the alternative is that their password could be compromised.
The fact that Twitter did not do this makes me wonder if they have that capability. Twitter passwords do not normally expire. Perhaps the Twitter engineers did not forsee the need. I can understand that, but we should learn from this incident. Even if you don’t think you need make passwords expire after a certain amount of time, it may be worth building a mechanism to flag a password as expired so the user needs to create a new one.
How can you use multiple strong passwords safely?
This has been a problem as long as there have been passwords. Here are three examples where I have run into bad password management.
One time I visited a secure company data processing site. Sometimes the clerks needed to do something relatively advanced that required manager approval. When the software was written, the manager would sign in and make the change. Over time, this sort of thing became so common that it was a big hassle for the manager. To make things easier, they simple wrote the manager’s password on a white board so everyone could use it. Now anyone could do anything without any effective record. (At least that room was designed intentionally without any windows so bad guys couldn’t peek in and steal the password.)
At similar data centers, I have often seen passwords posted in users’ cubicles on sticky notes or taped inside drawers where they were easy to find.
Finally, as an experiment, I once took my company’s encrypted password database and tried attacking it. It was a very simple attack where my program tried entering the users’ names and common words from a small dictionary as passwords. I was shocked when the program guessed about a third of the passwords in the database. If Twitter’s 330 million users have similarly bad passwords, that means a hacker could easily guess about 110 million of them!
And remember, as I said earlier, many users pick the same passwords for multiple systems. If a hacker can guess 110 million passwords, many of them may also give access to more sensitive web sites than Twitter.
So what can you do about it? First, always use strong passwords. I’ve written a couple examples that generate good passwords. (And I’ll post a new one in a day or two.) For example, see Use cryptographic methods to generate random passwords in C#.
Second, use a different password for every account.
Unfortunately, if a password is strong, then it is also hard to remember. In order to keep track of multiple strong passwords, use a password manager. You can buy them or download them for free. (Although I don’t know if you should trust one that you download for free.) The example Make a password manager in C# shows how to make a simple password manager in C#. A password manager lets you use a single strong password (which you need to remember–sorry) to access all of your other passwords.
Here are the lessons to take away.
- Never store unencrypted passwords in a file.
- Limit the amount of time that an unencrypted password is present inside your code.
- Use strong passwords!
- Use different passwords for every system.
- Use a password manager to keep track of your many strong passwords. (I have about 280 passwords in my password manager.)
- Finally, change your Twitter password if you haven’t done it already.