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.
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
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.
so.. they log all function calls and their variables? or just the pre-crypt ones?
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/...
replaces the actual password with a random set of numbers and letters
Personally I think that little line right there may possibly win an award for worst explanation of something ever. Hashing algorithms I use tend to always produce the same output for a given input every time, so the exact opposite of random. I really don't know how you'd auth somebody using random data. Maybe you just randomly state if the user authed or not?
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.
^^^ 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).
Nail 'em to the wall.
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.
It has to be in plain text somewhere along the path. How else would you pass it to the hashing algorithm?
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.
(e.g., try signing on as "user123 / pass123", then make sure "pass123" isn't actually in the log).
Hey! How did you know my password?!
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 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.
If they did that little hashing number client side, its never even a thought let alone a problem.
Hash client side. 1 password isn't going to take long no matter the algorithm.
It's hard to say how basic a security error this is, I mean, you're supposed to think hard before even logging the user id, because people will occasionally type in their password first.
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
so why cant that string be a common hash, sent to server side for further "secure" as you claim hashing? And I'm the moron.
I would rather someone have a SALTED hash than a plaintext password.
how do you do that without javascript? Not everyone uses it. With javascript, how do you hash without exposing the key?
How does that help? If I send a username and password, they were logging both and anyone with access could log in as you. If they were using your plan, I'd send a username and hash, they would still have been logging both and anyone with access could log in as you.
Hashing client-side seems like a bad idea - does anybody do this? The hashing function (as well as salt) would be exposed on the client javascript or whatever. I may be wrong - haven't worked on anything related to password security in 5+ years.
Neither the salt, nor the algorithm are considered secret. Nor is the password hash, by the way.
The standard model has the user and password files in plaintext available to all.
The only secret should be the password.
However, due to crappy implementations (such as allowing for social engineering, DoS lockouts, etc.) service providers like to consider the username secret. Due to using old algorithms and not having people regularly change passwords, they often consider the hash secret too. And the salt, And even the algorithm. Often, this is due to embarrassment more than anything else. How many times have we seen service providers get hit with a breach and then a year or more later sheepishly admit they had shit in plaintext, relied on MD5, didn't use a salt, had the last x characters in plaintext and readable by the support staff, effectively only used 12 characters (dropping the rest), etc.?
Hashing client side makes a lot of sense.
If the client side does the hashing, then the password is effectively plaintext - the Hash is the plaintext.
The entire _point_ of hashing is that the string provided by the client is not the string stored in the database, but can be confirmed to be a string that produces the value stored in the database.
Uh, hash it on both ends?
^^^ 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.
Correct, for various values of "database".
Example: if they are collecting all their log messages into something like Elasticsearch, then I guess you could call Elasticsearch a "database".
Of course, if they had a proper code review before pushing to production, anything logging PII, passwords, and the like would be found and rejected as part of the QA process. Or at least have logging levels per environment and if you're going to have something like this in there, log it at DEBUG level instead of INFO or higher, and leave production set to only log INFO and above. Test environments can still be logging at DEBUG so that you can see stuff like this... for debugging!
It's almost like logging levels have existed for decades.
Slashdot still doesnâ(TM)t support Unicode after it was added to the HTML standard in 1997.
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.People don't or shouldn't class action sue to make money or make lawyers rich. It is done for pure revenge on the perceived evil entity which screwed you over to begin with. All the other stuff is just annoying background noise.
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.
Ok so as someone has already stated.
if you did use client-side hashing in the first place, and only stored a one-way hash of the already hashed&salted password, you could indeed consider 'asdflkjh1234poiu' your password - TO ACCESS THIS ONE SPECIFIC SERVICE (Twitter). There would however never have been such massive headlines of a leak, because users' plaintext passwords - that they use in many different services - would not have been leaked.
Thanks AC
Now, Like he says.. YOU dont have my real password for one. but whats stopping the server from then hashing the hash I send if they think theyre going to get hacked? I dont understand why you guys are throwing the baby out with the bath water.. I dont give a fuck if someone gets a salted hash of my password. because they have no fucking idea what my real password is. also there is no chance of them doing the apparently common thing of storing it in clear text(i say its common because if you try to claim it isnt then you havent actually been paying attention) It is INSECURE to send YOUR password in clear text to any service or server.. Why does sending the plaintext password become more secure than not sending it? I dont get it. Nobody has been able to explain to me how somebody gets my actual password the way i suggest doing it. the way thats common to do it today. well there are databases with billions of passwords for everybody to see thanks to it.
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.
youre looking at it wrong, the employees that had access to that log probably had access to that whole site. they could do whatever they wanted with your information you have stored there whether there was a password or not. now $randomhacker gets ahold of that log, and starts testing user pass combos on other sites.. with a pre hashed password.. he gets nothing. with the plaintext password sent from $pleb1 used on $site1-12 $randomhacker gets $popularsite2-4 login information for $pleb1. make any more sense what im talking about.. minimize risk during breeches. because the breeches are going to happen, too much new development on the internet to not happen. you cant secure from thousands of changes a day.
if HTML isnt able to securely hash multiple algorithms by now, they need better devs.