Twitter Recommends Changing Your Password Following Plaintext Exposure Glitch

THAT’s how you handle a situation like that.

Ah, celebrities take note. For a limited time, you can claim that you didn't actually post that tweet yourself but rather someone hacked into your account due to this mistake!

Oh no, it won't let me add a password of more than 280 characters! ;)

All of those commenting about firing the person responsible, are completely ignorant to how the business world and technology works.

Software has bugs. There are mistakes. If you fired everyone that made a mistake, you'd set a precedent that would instill fear in everyone else. No one would want to dare make a single mistake, for fear of losing their job and thus everything grinds to a halt.

These companies have become what they are by innovating and pushing forward. You fire people for mistakes (look up the definition, I didn't say malice) then you'd either fire everyone or stop all growth and progress.

People responsible in these situations aren't fired. That's simply not how it works.

My question is why the plaintext password is even sent to them for password resets. There's zero reason for that. Shouldn't it just be validated and hashed by the webpage's script before sending?

There is no hashing done by web page scripts unless the site you are on uses Javascript for both the front end and back end (such as with React, node.js, etc.). Twitter is not one of those sites. However, values are encrypted over the line due to the SSL certificate (why you see HTTPS in the browser), but those values are decrypted on the server. The web server has to handle them somehow, and certainly can't validate anything, create new records (tweets, users, etc.) or update anything (such as your user profile) if it's just garbled encryption. It is not plaintext over the line.

This is inexcusable. Which developer had the bright idea to store passwords to a log file? That should never happen, ever. There's no reason for it.

Twitter was built on Ruby on Rails. It has, I believe, since migrated to another platform, but many of the concepts still remain, regardless of framework used. In Rails, for example, everything is logged - all parameters sent from a form (login info, new tweet message, profile settings, etc.) go to the log file, as well as database transactions and manual log messages.

In real world applications, regardless of programming framework used, logging either goes to an actual file on the drive of a server, or to a drain that feeds the log line-by-line to a service (so it can be searched or you can receive alerts on errors, etc.). There are also multiple levels of logging depending on what needs priority - everything from fatal and error messages that have higher priority, to info and debug messages for general system events. Things like this would have been an info message with parameters received from a client, POSTing to a particular endpoint. Those basic info and debug messages can be omitted from production logs, which does make debugging errors more difficult, but is often done for security purposes (the "use a sledgehammer to hammer in a nail" approach).

In most cases, the application framework employs sanitizers to mask sensitive parameters from being sent to the log (i.e. passwords, credit card numbers, social security numbers, etc.). This happens in a configuration file that isn't touched often, if ever, after the application is deployed on a website. Additionally, masking sensitive parameters occurs in production but not always in local development, since building, updating, or fixing features requires a higher level of knowledge of what's going on vs. once something has gone live.

My guess is they either accidentally turned off the sanitizer, changed the password field name or are using an alias field name to prevent bots (most likely case), or never masked it in the first place and decreased the log level for debugging purposes. It's a simple mistake that isn't easily apparent.

In any case, this happened on their end, they noticed it, and they let us know. There's no indication that anything has actually been accessed. And, even still, with most accounts using 2FA, most users staying perpetually logged in, and with API keys being how external applications authenticate to your Twitter account (not with your password), the likelihood of your password even showing up in the log is very slim anyway. I'm not saying you shouldn't change your password (because you absolutely should), but this sounds much scarier than it actually is.

I have Two Factor Authentication turned on with my Twitter account. If they had my password, it is useless to them.

This is inexcusable. Which developer had the bright idea to store passwords to a log file? That should never happen, ever. There's no reason for it.

and are implementing plans to prevent this bug from happening again

I hope that means they fired the person responsible, or sent them back to primary school to learn basic common sense.

No, where does the website need the plaintext password instead of the hashed one? They just hash it then throw it away ASAP. Any validation can be done with the hashed one. Nearly every site uses JS for frontend, not that you need JS to do hashing.

Say I write a browser extension that hashes all passwords sent in forms before sending them, always using the same salt. With no other changes, that would work fine with every website. Heck, maybe I should do that.

You aren't a developer, are you? Rule number 1 of making a secure product -- never trust the input you've been given by a user. This means you don't validate/hash on the client because you can't trust that they did it correctly. Furthermore, client-side encryption is not encryption. You can't just store your encryption algorithm/salts in javascript for everyone to see and think that that's somehow more secure than plain text. You can reverse-engineer that in a heartbeat. The industry standard way of transmitting form information (including passwords) is to use TLS encryption to encrypt the entire communication between server and client, and transmit plain text over that encrypted line. This is how the server knows that you didn't use enough characters, or your password is not strong enough, etc, etc. As others have said, most web applications log the POST parameters to a file, though they usually sanitize the log to keep out sensitive information. You'd be shocked how many companies out there don't even bother to encrypt your password before storing it in their database (scary, I know).

Got an email from GitHub saying the same thing. I guess they're using the same library somewhere.

Hi there,

During the course of regular auditing, GitHub discovered that a recently introduced bug exposed a small number of users’ passwords to our internal logging system, including yours. We have corrected this, but you'll need to reset your password to regain access to your account.

GitHub stores user passwords with secure cryptographic hashes (bcrypt). However, this recently introduced bug resulted in our secure internal logs recording plaintext user passwords when users initiated a password reset. Rest assured, these passwords were not accessible to the public or other GitHub users at any time. Additionally, they were not accessible to the majority of GitHub staff and we have determined that it is very unlikely that any GitHub staff accessed these logs. GitHub does not intentionally store passwords in plaintext format. Instead, we use modern cryptographic methods to ensure passwords are stored securely in production. To note, GitHub has not been hacked or compromised in any way.

You can regain access to your account by resetting your password using the link below::

https://github.com/password_reset

If you have any lingering questions or concerns about this, don't hesitate to let us know. You can reach us by emailing support@github.com or by using our contact form:

https://github.com/contact

Thanks,

GitHub Support

My question is why the plaintext password is even sent to them for password resets. There's zero reason for that. Shouldn't it just be validated and hashed by the webpage's script before sending?

The comments for this post are gold. :p

Also I opened up Twitter and this popped out. Glad they're alerting everyone of this.