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.
dumb twats not understanding proper coding
Why do they have the fucking passwords!?
Ok, that's it. Can anyone recommend a reputable life lock style service? One that isn't owned by the same incompetents who created this endless fuckstorm?
It's clear I need once, since there's no level of care I can take that will compensate for every single service I use being completely untrustworthy.
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.
"which replaces the actual password with a random set of numbers and letters that are stored in Twitter's system"
I'm pretty sure the numbers and letters selection is pretty deterministic
The password leak was obviously Russian bots.
All things bad are Russian bots.
Russian bots are so powerful that they can change people's minds with a word and compromise entire social networks with two dozen keystrokes.
And we know that all bad things happen because of Russian bots. We know this because we are reminded of this fact constantly. If it wasn't for these daily reminders that Russian bots are responsible for all evil things and all hax, we might start to suspect that maybe it was not malice, but simple incompetence or internal leaks. In fact, we might start to think - OH, WAIT! THERE'S A RUSSIAN BOT!!!1!
You would think that by now, not storing (or if possible even transmitting) passwords in plain text would be common sense or something that they teach in school. Developers found violating that principle should be sent to a reeducation camp and have that point driven into them, possibly with a mallet.
Whoever wrote that code probably had some PRINT or LOG statements to get some insight that everything was working correctly, than forgot to remove them when they did a commit.
Source: I've made this mistake before
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.
I don't understand why anyone would use bcrypt. Although scrypt is newer and in terms of security, that usually means safer. scrypt requires a lot more memory which isn't a problem for their servers when comparing hashes, but it blocks FPGAs from brute force attacks.
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.
so.. they log all function calls and their variables? or just the pre-crypt ones?
A "glitch" is something that happens to you. This was something Twitter did to itself.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
It seems to me, a majority of technology companies seem to not be learning. We've been here, before. More than once. And it's not exactly news that you never store a plain-text password anywhere, ever.
I mean what the hell are they teaching in computer science courses now? This should not be happening, so frequently. An occasional lazy outlier perhaps, but big tech firms like Twitter? No excuse. They should be fined by some government entity, obviously just the bad publicity isn't enough to get companies to do the right thing, perhaps some fines will right the ship of irresponsible handling of user data.
Seems like this log wasn't being looked at by anybody outside of Twitter, so there's no hack and no "exposure" so I doubt we'll see a world-ending password release here.
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
... or feature asked for by US information authorities.
I wonder which.
Why would they log plain text passwords?
Who's next? Are they all reading from the same playbook?
This definitely smells fishy and strange. For two tech companies to make an absolute beginner's mistake like this, at the same time.
I don't know what the exact purpose is, but I'm guessing one possibility is to match developer accounts to twitter accounts, simply for building profiles and establishing connection graphs.
Now how am I going to come up with another password as memorable and clever as "1 2 3 4 5" ?!? That shit was BULLETPROOF, and totally NOT the sort of thing an idiot would have on his luggage!
Guess I'll have to change it to "1 2 3 4 5 6"!!! Don't tell anyone! It's MY password and YOU can't use it. You have to pick your own.
Our reign has gone on long enough. Indeed. Summon the meteors.
How would you recommend that each user authenticate himself or herself to the server of Twitter, Slashdot, or any other forum-like web application?
Sending the password The user provides a password over a TLS channel through a form or HTTP basic authentication, which the server hashes and compares to the stored hash. Most public websites that I'm aware of use this method. HTTP digest authentication with a fixed realm The server sends a fixed salt in the realm field, and the user's browser sends the hash of a (username, realm, password) combination to the server. This not only uses the deprecated MD5 algorithm but is also vulnerable to pass the hash attacks. HTTP digest authentication with a variable realm The server sends an IV in the realm field, and the user's browser sends the hash of a (username, realm, password) combination to the server. This not only uses the deprecated MD5 algorithm but also requires the server to store the password (not just a hash thereof) in order to verify that the hash is correct. Some zero-knowledge proof means Because a zero-knowledge proof isn't defined in the HTTP spec, it requires the user to download a program from Twitter's server and execute it on his or her computer. This fails if the user has turned off automatic execution of script in the browser. Using a client certificate TLS allows a user agent to identify itself using a certificate, much as with an SSH client key. But its usability in current web browsers is so terrible that I can think of only two websites that have used it: StartSSL (RIP) and Kount (an e-commerce fraud detection service). Some option that I haven't thought of I'd be interested to read your reply describing such a method.I work in Information Technology in healthcare. Do you know how many chances we get to get it right? 1. 1 chance, before I get nailed to the wall for screwing up security, but non-healthcare entities, like Equifax and Twitter and Yahoo all get either completely absolved of all liability, are allowed to profit from their idiocy or are fined a pittance.
Fantastic work here. Please continue /s
I found your comment difficult to read because of the lack of sentence-initial capital letters, quotation marks, and line breaks.
Ok, first stop using MD5? that sounds like a start.
RFC 2069 specifies that HTTP digest authentication shall use MD5. Switching from MD5 to anything else would require the use of JavaScript. The use of JavaScript would require counterpart functionality in the noscript element.
second, encypted session(lets get as secure as we can before we do any auth)
TLS. I'm with you so far.
Server says how do you expect me to believe you, here is an algorithm.. the same as the one you signed up with(you can even do a rolling algo with a flag in the database per user) also heres a salt to use.
What you describe is in essence what I described earlier as "Some zero-knowledge proof means", for which I warned: "This fails if the user has turned off automatic execution of script in the browser." Here's how the next step would play out in detail:
Client says "I am running the LibreJS extension. Before I run any code, I'll need to see that code's copyright license to ensure that my user has the right to audit the algorithm you are sending, in order to ensure that your program isn't unduly intrusive on my user's privacy or otherwise malicious, and share the results of this audit." Quoting FSF's Free Software Definition, the user will need the following rights:
The GNU General Public License defines a work's "source code" as "the preferred form of the work for making modifications to it." A minified or obfuscated form of a script is instead called "object code", even if it is in superficially the same syntax as source code.