Twitter blog:
When you set a password for your Twitter account, we use technology that masks it so no one at the company can see it. We recently identified a bug that stored passwords unmasked in an internal log. We have fixed the bug, and our investigation shows no indication of breach or misuse by anyone.
And:
We mask passwords through a process called hashing using a function known as bcrypt, which replaces the actual password with a random set of numbers and letters that are stored in Twitter’s system. This allows our systems to validate your account credentials without revealing your password. This is an industry standard.
Due to a bug, passwords were written to an internal log before completing the hashing process. We found this error ourselves, removed the passwords, and are implementing plans to prevent this bug from happening again.
This seems like a pretty major slip-up. The way I’m reading this, somewhere internal to Twitter, your password was stored “unmasked”. And to me, that means in the clear, in plain-text. Am I misreading this?
No matter. Go to Twitter Settings and change your password.
You are not misreading that.
(I mean, “internally in a place no outsider had access to and we have no evidence of any breaches allowing it” is how I read that, and that means it’s not exactly earthshaking.
Changing your password won’t be a bad idea.)
I was prompted to change my password the first time I went back to Twitter this evening. Storing passwords in logs isn’t brilliant, but the response seems pretty ideal thus far.
That’s good to hear. I missed that, but maybe because I was clicking through to the password change screen quickly on my own. 🙂
It sounds like there was one or more logging statements that included the password, probably included for debug purposes and accidentally left in.
Assuming the logs weren’t stolen and have since been destroyed, it’s not a big deal. But it’s almost impossible that they’re sure all copies have been destroyed, and changing your password is something you can do to eliminate the risk in any case.
In an ideal world, the service would guide people through changing their password.
Steven got it exactly right. If the logs were being dumped into an aggregator (e.g. ELK) and the logs were being rotated then they may have cleaned out the problem.
I have it on good authority that this sort of thing happens a lot more than we realize and most companies never disclose it when it does.
Update: I got that prompt the next day. 🙂