Twitter Stored Passwords in Log File
Twitter (Hacker News, MacRumors):
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.
The euphemistic and misleading headline upsets me. What’s even more worrying is Agrawal’s reaction in a tweet[…]
We are sharing this information to help people make an informed decision about their account security. We didn’t have to, but believe it’s the right thing to do.
This is weird, @Twitter. Shouldn’t you be hashing the passwords on the client side, BEFORE sending them to the server?
So first, and most importantly, never reuse passwords, no matter how trivial. Eventually any company will screw up or be hacked, and your password exposed, and then someone can try it on every other site.
It took us a while to find what we needed for this layer. (Apparently the marketing department of augmented password-authenticated key agreement protocols is underfunded.) But we eventually found SRP, which ticked all our boxes. SRP is a handshake protocol that makes multiple requests and responses between the client and the server. Now, that may not sound very interesting – and I’m not one to show excitement easily – but SRP is a hell of a layer. With SRP we can:
- authenticate without ever sending a password over the network.
- […]
Previously: High Sierra Stored APFS Volume Passwords in Log Files.
3 Comments RSS · Twitter
CTO Parag Agrawal:
We are sharing this information to help people make an informed decision about their account security. We didn’t have to, but believe it’s the right thing to do.
Uh, I would say, yes you did. Jerk.
Warning all clients now to update passwords on Twitter. Including companies.
>Shouldn’t you be hashing the passwords on the client side, BEFORE sending them to the server?
No. That would completely defeat the purpose of hashing, because an attacker can just send a leaked hashed password to the server, and log in with it. So hashing on the client would not have prevented this problem, because the client-hashed passwords would have been in the logs, and those passwords could have been used to log in. In other words, you're just substituting one plain-text password with a different plain-text password.
You can hash passwords on the client *in addition* to hashing them on the server, but that is to (slightly) mitigate a completely different problem (it can make dictionary attacks more expensive). It's borderline worthless, so few websites do it.