Slashdot Mirror
Twitter Says Glitch Exposed 'Substantial' Number of Users' Passwords In Plain Text (reuters.com)
Twitter is urging its more than 330 million users to change their passwords after a glitch exposed some in plain text on its internal computer network. Reuters is first to report the news: The social network said an internal investigation had found no indication passwords were stolen or misused by insiders, but that it urged all users to consider changing their passwords "out of an abundance of caution." The blog did not say how many passwords were affected. Here's what Twitter has to say about the bug: "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."
The social networking service is asking users to change their password "on all services where you've used this password." You can do so via the password settings page.
The social networking service is asking users to change their password "on all services where you've used this password." You can do so via the password settings page.
Twitter is urging its more than 330 million users to change their passwords after a glitch exposed some in plain text on its internal computer network.
Remember couple years ago when the oft-quoted number of Twits was ~500 million? Ouch on the downgrade. They can hate on Trump internally all they want, he closes his account their total traffic goes down by 10% probably. Twitter needs Trump...think about that one for a sec.
Due to a bug, passwords were written to an internal log before completing the hashing process.
Repeat, that is not a bug. That is intentional. It was designed to do this. You cannot call an intentional act a bug.
You could, of course, just read the blog post to get your answer. But since you're not only an anonymous coward, but a lazy and/or incompetent one as well:
"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."
One site being affected by bug this is a fluke. Two being affected by the same bug is a pattern.
This seems like an awfully convenient way for someone to maliciously gain access to somebody else's account on sites that do stupid things like locking you out after a certain number of failed login attempts:
The best part is that this could even allow someone to compromise specific accounts on sites that encrypt all user data while in stable storage and in backups, unless those sites also encrypt all of their log data.
For now, I'm willing to give the parties involved the benefit of the doubt and assume that this was just an accident, or possibly two accidents, and assume that somebody at Twitter read the story about GitHub and thought, "I'd better make sure we don't do that." That said, the possibility that a bug like could this exist in some sort of production software that would be shared by such disparate companies as Twitter and GitHub is downright alarming, and the possibility that this was malicious should at least be in the back of everyone's minds right now.
Check out my sci-fi/humor trilogy at PatriotsBooks.
They didn't store the password in plain text (intentionally). They appear to have a user action logging system that logged user inputs, including the password field. Just as dangerous, but at least they gave it some thought.
Plain text is not a glitch ... it is bad security! For a company of that size that tells you something about how secure they might be.
Just send me all your account information, particularly for banking and credit cards. I'll personally lock your shit down so tight that you won't ever be able to get into it again.
To clarify this: when a user logs in, they have to provide their password. Most likely, their HTTPD was logging the entire POST header of ALL requests, regardless if it potentially stored sensitive information or not. This occurs before the application receives the data and can hash it. This is a potential security issue on virtually every HTTPD that is misconfigured. GitHub just announced pretty the exact same thing earlier this week. Odds are one of these announcements triggered an audit in the other's organization to look for the same misconfiguration and they found it. https://www.zdnet.com/article/...
The passwords are not transmitted in plain text; they are transmitted through a TLS channel. The storage was intended to be as a bcrypt hash value, not as plaintext or even as ciphertext. The storage described in the featured article was a mistake apparently during debugging, which was discovered and corrected, presumably before the result could leak.
Why do they have the fucking passwords!?
This question was answered in the discussion yesterday.
But honestly, This should be handled client side not server side. that plaintext password should never be sent over HTTPS even, I haven't played with web development in about 20 years, so I cant say how easy this is to do. But I can say that if its not easy to do in HTML/CSS/PHP/Whatever is used, there is something wrong with the language and it should probably never be used for secure access to anything. Just my 2 pennies worth.
It is easy to log passwords without knowing. If you use mod_security for Apache, have a look for Authorization headers in modsec_audit.log
The sanitiseRequestHeader operation is supposed to clean that up, but there are situations where it is not run
^^^ this ^^^. This kind of mistake is worth a little class action. Non-negligent companies don't deploy noob code like this ("der...dump all POST input because we have our fingers in production...herp!") on the machines that actually parse the passwords (or any other sensitive data). Non-negligent companies also have tests for exactly this kind of thing (e.g., try signing on as "user123 / pass123", then make sure "pass123" isn't actually in the log).
Yes. Sue them for every cent you never paid them to use thier free service. Recall that your ability to do so was predicated when you signed up for an account, (without which there'd have been no way for you to use the service,) upon your agreement that you understood the provider (Twitter) was not liable for damages to you of any kind arising through your use of the service, blah blah blah. Best of luck with your "class action". Oh, odds are there won't be one because by using Twitter, you probably signed away your rights to sue, and will instead be forced into binding arbitration, from which you will get literally nothing.
Oh, PS, BTW... class action lawsuits, when they CAN and DO actually go forward, make class action attorneies rich when they win, and after those costs are paid, net almost vanishingly small benefits for members of the injured class, which years later if your side wins, when you finally get them, are worth so goddamned little that it ends up not even being worth the time it took for you to read what you had to for the bullshit settlement.
For example, I was once part of a class for a lawsuit against 24 Hour Fitness, over their marketing practices, about 8 or 10 years ago. Years later, I got a check for a whopping TWENTY FIVE DOLLARS! Holy fucking shit, I shouted when I found out about how much I would one day receive a check for, I'm gonna be fucking rich! then I went about my otherwise shitty day, that that announcement of a preliminary agreement to a settlement made no impact on. About 3 or 4 months later, I got the check, and had dinner at a nice, fairly fancy Korean resteraunt, and had almost enough left over from the check for ice cream.
But again, good luck suing Twitter for "damages."
Our reign has gone on long enough. Indeed. Summon the meteors.
So your password is 'hunter2', and clientside, you hash that to 'asdflkjh1234poiu'. That still has to be sent back to the server, and the server has to validate it somehow. Congrats, your password is now 'asdflkjh1234poiu'. It doesn't matter that I don't know that you typed in 'hunter2' to get to 'asdflkjh1234poiu', all I care about is that if I send 'asdflkjh1234poiu' down the wire in the password field with username 'Highdude702', the server lets me in. I don't care that your password is 'hunter2' and not 'asdflkjh1234poiu', I care about accessing your account.
Now, lets think about the practicality of this situation. You HAD to have transmitted hunter2 to the server during registration. If you didn't, the server couldn't have been able to generate a hashed version of it. It's pointless saying 'but you can use 'asdflkjh1234poiu' which I hashed clientside for you already', because then that's the equivalence of a cleartext password.
Next, you need to understand how bcrypt works. It takes your cleartext password 'hunter2'. It then adds a salt to it, performs a random number of iterations of a hashing algorithm on it, and stores the salt and the random number along with the resulting hash. You can't reverse this, even knowing the number and hash. What you can do is take a given input from the user, e.g. 'hunter2' and add the same salt to it, and repeat the algorithm the same number of times, and compare the resulting hash to what you've got stored.
Let's say you no longer want to transmit plaintext passwords. So you ask the server for the random number and salt associated with Highdude702, and you do the bcrypt clientside, and transmit that to the server, so the server only has to compare what you transmitted with the bcrypt it's got stored. Congrats, your bcrypted password is now a cleartext password, because you're just doing a straightforward string compare. If I get the db from the server, I can login to your account with not extra effort whatsoever.
You can't change the salt or the number of iterations clientside, because you'd then be unable to validate your password against the hashed version on the server. The whole point of it is that it's not reversible to get your cleartext password out.
There are of course ways of transmitting an encrypted password to the server, but at some point they have to be decrypted on the server to be able to re-hash them and compare against the one-way hash that the server is storing. So you're back to transmitting a password, except its reversibly encrypted (since it has to be decryptable on the server), which means that someone else could also decrypt it if they breached the server (or your client), so it's only slightly better than transmitting the cleartext password. So you might as well just use TLS and send the cleartext password anyways, because with TLS, you know upfront if someone is MITM your connection via a cert validation failure.
Then there are other ways of transmitting your password securely, but they introduce additional complexity on server and client, and everywhere that additional complexity is introduced, you increase the potential for bugs, which could be security issues. You also typically introduce user-unfriendliness, which means that the majority of users will either not use your platform because its too unfriendly, or will choose to use the less secure login method, because its more friendly. Either way, you're back at square one.
There's nothing wrong with transmitting your password in cleartext over TLS, as long as the server is storing the passwords as a one-way hash, which Twitter (and GitHub) are doing.