Twitter Says Glitch Exposed 'Substantial' Number of Users' Passwords In Plain Text (reuters.com) 107
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.
Re: (Score:2)
Nail 'em to the wall.
Re: (Score:2)
(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?!
Comment removed (Score:4, Informative)
Re: (Score:2)
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.
Re:Why do they have the fucking passwords!? (Score:5, Informative)
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."
Re: (Score:2)
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 hi
Re:Why do they have the fucking passwords!? (Score:5, Informative)
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/... [zdnet.com]
Re:Why do they have the fucking passwords!? (Score:4, Insightful)
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.
Re: (Score:2)
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, An
Re: (Score:2)
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.
Re: (Score:2)
I would rather someone have a SALTED hash than a plaintext password.
Re: (Score:2)
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?
Re: (Score:2)
Re: (Score:1)
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?
Re: (Score:3)
Why do they have the fucking passwords!?
This question was answered in the discussion yesterday [slashdot.org].
Well now (Score:1)
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.
Re: (Score:1)
yo maybe you could use unique passwords
then when some stupid social media site gets hacked they dont have the login to ur bank
just sayin
Re: (Score:2)
Even with a good password vault, if basic security practices aren't in force, your data is up for grabs.
And your data is stored in so many places. It is, these days, not a matter of "if" but "when".
Re: (Score:1)
Passwords are not my concern per se. This is a symptom of endemic categorical incompetence. Plaintext. Holy hell! Plaintext!
I have to accept that my data can't be protected....scratch that, hasn't been protected and has been completely exposed many times for decades. I have to operate with that as the understanding. Security practices are only an option if I can trust service providers to...FUCKING PLAINTEXT!
Re: (Score:2)
Plaintext. Holy hell! Plaintext!
How else would you propose sending your password to a remote service for authentication? There are other such methods, but they're significantly more complex.
Re: (Score:1)
Well, I'm not an expert on these things, but I think I'd use https, filter the user input, hash and salt the submitted password, start logging, load and escape the fields from the user database, and compare. Or use a third party login service so I wouldn't have to take the blame if something got gorked up, since as I said I'm not an expert on these things.
Re: (Score:2)
Well, I'm not an expert on these things, but I think I'd use https, filter the user input, hash and salt the submitted password, start logging, load and escape the fields from the user database, and compare.
I've highlighted the time when the password is plain text.
Re: (Score:2)
I'm sure he means Client Side not Server Side, so the only thing transfered is a salted hash.
Re: (Score:2)
Re: (Score:2)
there is a difference between a user password, and a salted hash. one is safer than another to transmit. and they can both be re hashed on the other side, it just becomes less exposing to do it one way and not another, also prevents a breech in one service from effecting another unless its a source copy.
Re: (Score:2)
there is a difference between a user password, and a salted hash. one is safer than another to transmit.
What makes you think that sending a password that looks like a hash is safer than sending a password that doesn't look like a hash?
Re: (Score:3)
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.
Re: (Score:2)
I use pwsafe and I push the (encrypted) password file to git.
Downward trends...har-har. (Score:3, Interesting)
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.
Re: (Score:2)
Re: (Score:3)
Yes, only the ones that actually use the service and log in.
Re: (Score:3)
Re: (Score:2)
Re: (Score:3)
It's the howard stern phenomenon all over again. The people who disliked him the most, were also sure to tune in just to be annoyed and offended.
Not a bug (Score:2, Insightful)
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.
Re: (Score:2)
Never underestimate the power of human stupidity.
Irrelevant but still (Score:1)
"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
Re: (Score:1, Insightful)
Not irrelevant. And "back in the day", a lot of folks would have noted this right off, and posted under their actual logins, instead of being afraid for making geeky observations about the weakness of the writing/editing.
I'm pretty sure this response comment will get modded down, but hey. Old /.ers don't die, they just get modded into oblivion...
Re: (Score:1)
Why does this still happen? (Score:1)
Re: (Score:3)
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.
Re: (Score:2)
If they did that little hashing number client side, its never even a thought let alone a problem.
Re: (Score:3)
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.
Re: (Score:1)
The plain text passwords should never have been transferred to their servers, whether its through TLS or not.
Alternatives to sending the password (Score:2)
How would you recommend that each user authenticate himself or herself to the server of Twitter, Slashdot, or any other forum-like web application?
Re: (Score:2)
Ok, first stop using MD5? that sounds like a start. second, encypted session(lets get as secure as we can before we do any auth) server says who are you, client says im John Smith. 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. client says, second mate i need to run this shit quick ill get back with you in a second. client hashes, sends hash over encr
Running a server-defined program on the client (Score:2)
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
Re: (Score:2)
So essentially after ~30(?) years HTML is still shitty. I kindof figured that from the other posts. Maybe browsers could implement the rolling hashing portion of the deal, allowing the rest of those fields to be fulfilled. There has to be safer ways to do this. Sending plaintext passwords to anybody is a bad idea honestly. Negligence like this is the main reason, a lot of us have known this but your information isnt safe outside of your own network..
Re: (Score:2)
I'd prefer to use a TLS client certificate, but the user interface for those in widely used web browsers needs a serious redesign before that can be practical.
First, the browser needs to make the button to select a client certificate more obvious. Second, split the list of available client certificates into three groups: anonymous (no certificate), certificates used on the same domain (ordered by most recent), and certificates used on other domains. Third, browsers' built-in password/bookmark/history synchr
Re: (Score:2)
I got to here and cringed
are created and stored on an authenticator by the user agent in conjunction with the web application.
Its a good idea to not transferring the password, ill give it that.. or it seems so i only read the first page or so TENR(too early not reading).
The problem is now that password/phrase/key is stored on the client.. the client is the most insecure part of this whole process. 99% of people that end up being vulnerable when this stuff happens run windows. windows without a bunch of work is normally easy to break into. Now were back at the password manager issue we had a few years ago,
Re: (Score:2)
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?
Re: (Score:2)
Hash client side. 1 password isn't going to take long no matter the algorithm.
Re: (Score:1)
Re: (Score:2)
if HTML isnt able to securely hash multiple algorithms by now, they need better devs.
Re: (Score:2)
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.
Re: (Score:2)
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 sen
Re: (Score:3)
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
Re: (Score:2)
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
Twitter AND GitHub.... (Score:3)
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.
Re: (Score:3)
scrypt is better and an IETF standard (Score:1)
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! (Score:3)
Re: (Score:2)
Look at the user base, and staff.. Twirrer is popular for Trump, Botnets, and Spam.
SuperLog (Score:1)
"Glitch"? (Score:2)
A "glitch" is something that happens to you. This was something Twitter did to itself.
Not learning (Score:2)
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 compan
Zero day solve (Score:2)
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.
mod_security (Score:3)
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
Re: (Score:1)