Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror
×
Twitter Bug Communications Privacy Security Social Networks The Internet

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.
This discussion has been archived. No new comments can be posted.

Twitter Says Glitch Exposed 'Substantial' Number of Users' Passwords In Plain Text

Comments Filter:
  • 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.

    • by Anonymous Coward

      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

      • 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".

      • 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!

        • 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.

          • 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.

            • 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.

              • I'm sure he means Client Side not Server Side, so the only thing transfered is a salted hash.

                • At which point the salted hash becomes the password, and nothing has changed.
                  • 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.

                    • 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?

    • 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.

    • by godrik ( 1287354 )

      I use pwsafe and I push the (encrypted) password file to git.

  • by TheZeitgeist ( 5083373 ) on Thursday May 03, 2018 @04:39PM (#56549652)

    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.

    • by Ksevio ( 865461 )
      Maybe the bug only affected some of the users
    • I... that... look, that's... that's not how it works. Not at all.

      If something is failing now, saying "The problem is they might get rid of that person they're keeping on to" makes little or no sense.

      Trump might be the reason 170M people are gone. Or it might be the Neo-Nazis. Or it might be the harassment squads. Or it might be that their website is shitty and they keep adding "Features" nobody wants that actually makes it harder to use, like that idiot "Let's treat "likes" like "retweets"" thing they

      • Completely misunderstood what I was saying. Trump generates lots of traffic for Twitter because world basically watches his tweets. Whether you like him or hate him is irrelevant - he's just a big bump in their traffic. If they lost Trump for whatever reason (pick a reason) that traffic would go away. That makes Trump's continued engagement with the platform of particular material interest to Twitter.
        • 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)

    by Anonymous Coward

    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.

  • by Anonymous Coward

    "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)

      by forkfail ( 228161 )

      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...

  • 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.
    • 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.

    • by tepples ( 727027 )

      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.

      • The plain text passwords should never have been transferred to their servers, whether its through TLS or not.

        • 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 (u
          • 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

            • 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

              • 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..

                • by tepples ( 727027 )

                  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

                  • 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,

    • 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?

      • Hash client side. 1 password isn't going to take long no matter the algorithm.

        • by zabbey ( 985424 )
          how do you do that without javascript? Not everyone uses it. With javascript, how do you hash without exposing the key?
        • by E-Rock ( 84950 )

          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.

          • 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

        • by beuges ( 613130 )

          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

          • 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

  • by dgatwood ( 11270 ) on Thursday May 03, 2018 @04:52PM (#56549788) Homepage Journal

    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:

    • First, find a way to gain surreptitious access to the site's logs (or gain access via a gag-order-protected subpoena later).
    • Second, introduce a bug in bcrypt that logs the unencrypted password.
    • Third, enter a wrong password until the user gets locked out.
    • Fourth, wait for the user's new password to show up in the logs.

    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.

    • by mark-t ( 151149 )
      No... one is a fluke, two is coincidence, and is only cause to watch for patterns. *THREE* is a pattern.
  • 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.

  • by kiviQr ( 3443687 ) on Thursday May 03, 2018 @05:04PM (#56549880)
    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.

  • 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

  • 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.

  • by manu0601 ( 2221348 ) on Thursday May 03, 2018 @08:46PM (#56551282)

    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

  • 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.

What this country needs is a good five cent ANYTHING!

Working...