We just received a warning from Twitter admitting that the company had made a serious security blunder: it had been storing unencrypted copies of passwords.
You read that correctly: plaintext passwords, saved to disk.
What an announcement to have to make on World Password Day!
Any regular reader of Naked Security will know that plaintext passwords are an enormous no-no.
It’s OK to have passwords in memory temporarily when verifying them at login time, but that’s all you should ever do with raw passwords.
You shouldn’t write passwords to a temporary file that you intend to delete later – your program could crash before it cleans up properly, or the disk where you wrote the data could be unmounted before you’ve finished.
You shouldn’t even keep passwords in virtual memory that the operating system might page out into the system swapfile, lest the passwords get flipped out to disk when the system is heavily loaded.
On Windows, you can use the VirtualLock() system function to keep memory blocks “locked into” physical RAM, thus preventing them from getting paged out to the swapfile.
You really, certainly, absolutely shouldn’t let unencrypted passwords get saved anywhere that’s supposed to be permanent…
…and that most definitely means taking great care that you DON’T WRITE PASSWORDS INTO LOGFILES BY MISTAKE.
Unfortunately, that’s what Twitter realised it’s been doing, thus its mea culpa warning today.
The good news is that the password databases actively used by Twitter to patrol logins were implemented securely.
Twitter uses bcrypt, an algorithm that performs what’s known as salt-hash-stretch to turn passwords into cryptographic checksums that you can later use to verify that a password held temporarily in memory was supplied correctly.
That’s because a password hashing procedure as bcrypt lets you work forwards from a supplied password to match it against the stored password hash, but not to work backwards from the hash to recover the original password.
Even if crooks hack in and steal the password file, they can’t just read the passwords out of the purloined database.
Instead, they have to try every possible password (or try a “dictionary” of likely passwords) against each user’s hash and see which passwords they were lucky enough to guess correctly.
The bad news here, of course, is that the safety provided by using bcrypt for password verification was undone by writing plaintext passwords to the system logs.
If the crooks went for the logs instead of the password database, they could extract the logged passwords directly, with no cracking or “dictionary attacks” required.
What to do?
Twitter claims that it has now “fixed the bug” and that its investigation “shows no indication of breach or misuse by anyone”.
Twitter therefore suggests merely that you “consider changing your password”.
We’ll go one step further and urge you to change your password – after all, Twitter isn’t saying how long it’s been logging passwords, or how many it collected by mistake along the way, so there’s no way to judge how far and wide any saved passwords might have been replicated by now.
We also suggest that you start using Twitter’s two-factor authentication system, also known as login verification, if you aren’t already.
This means you need to supply a single-use code that’s sent to, or calculated by, your mobile phone when you login – your password isn’t enough on its own.
Should you stop using Twitter altogether on account of this carelessness?
That’s up to you, of course, but we suggest that changing your password promptly is enough.