Twitter Admits All Passwords Visible to Employees Due to ‘Bug’ and Advises Password Change

originally posted by: xuenchen
a reply to: roadgravel

I think they got caught and were "told" to publish an excuse.

Sure seems likely. How could this be missed for all these years.

They are saying they were writing passwords to a log during hashing.

WOW ! Twitter Passwrds dump! Quick give them to McCain while he plans a Cyber-attack on Russia. It's gonna be cool!

Best practice you could enforce is different password for everything consisting of random numbers and letters, and store them all in a text file that is itself stored in a (heavily backed up) encrypted zip or rar file. Should be ok to store that thing in dropbox because its encrypted but ya your choice ;p

Hahaha,I don't use book face,you twitter or media for social anything. State of the times?

a reply to: xuenchen

Twitter has "announced" as many as 300 million user passwords have been visible to lots of employees because of a "bug" !!

WTF are they insane? How about damn encrypting the passwords! This is so no go!!! This is why I also stay away from an site where I can retrieve my password in cleartext. It´s just THE WORST PRACTICE EVER.

My god we´re living in 2018 and there are still idiots doing this. UNBELIEVEABLE!!!!

Bug my ass. Protected data fields are secured with ACL's and encrypted. If you hold an access token, or are a member of a group that can be assigned to the ACL, then you have access to that field. It is the MANAGEMENT of the database, not the system that is at fault here.

originally posted by: roadgravel
They are saying they were writing passwords to a log during hashing.

Yeah, kind of defeats the purpose of hashing, huh?

Weirdest bug ever - or a neat little tool to gather information by someone inside. I know which one I find most likely.

a reply to: DupontDeux

Right? This smells very intentional.

Let´s take this apart:

-We know there are plain passwords.
-It´s said those passwords were written to a log during hashing.

This gives two options:

a) Passwords were always stored in plaintext.
At some point this was determined bad practice by the team and they wrote a function to hash every password. Knowing that things can go wrong and millions of users won´t be able to login, they streamed each password into a logfile for later recovery.
Problem with this theory: You can also backup the database, and I bet money it is done regulary. So why not rely on the backup if things go tits up?

b) Passwords were hashed on registry as they are supposed to be.
Yeah, WHY would you then save the plaintext data if you already hashed the password to begin with? Clever employee?


It´s either incompetence or pure intent.

originally posted by: DupontDeux

originally posted by: roadgravel
They are saying they were writing passwords to a log during hashing.

Yeah, kind of defeats the purpose of hashing, huh?

Weirdest bug ever - or a neat little tool to gather information by someone inside. I know which one I find most likely.

Sounds like a debugging/monitoring during development issue that was forgotten (kinda hard to believe) or someone snooping.

I am with the snooping also.

Since hashed text cannot be recovered, maybe this was a way to have a clear password should the feds show up and want a user password. Twitter has demonstrated user privacy isn't a priority but their money machine is.

a reply to: roadgravel

Maybe I´m overthinking this.. If they would be willing to access their DB to get the plain password, they could aswell reset a hashed one and later reinsert the correct hash. Or just grant them direct access to their DB instead of the user-gui.

Makes the data export much easier than doing it via HTML or by hand

a reply to: verschickter

All the data for the user could be given out if required. I thought that law enforcement might want passwords, if possible, due to the fact that many people reuse them and it might be useful in another investigation. Probably low chance in reality, they would want data.

If hashing is used then the plaintext goes away and is never known by anyone but the user. For real security, it never saved.

I am leaning toward some one there deciding as list would have value, such as dollars in a sale. I find it hard to believe this is an overlooked programming issue.

Now if it was a security upgrade issue, testing would show the conversion would work so do and remove the plain text. If the system is having to guess whether the system is working and then falling back onto the plain text, that is even a bigger security issue.

If the "log" isn't a DB table, but a flat file then to me it points to suspicious actions. Someone tracking some thing they shouldn't. But this is just me, I would not be shocked over some really screwing coding practices today or the near past.

It's unclear exactly why user passwords were stored in plaintext before they were hashed. Twitter said that it stores user passwords with bcrypt, a stronger password hashing algorithm, but a bug meant that passwords were "written to an internal log before completing the hashing process."

...

A source familiar with the ongoing investigation told ZDNet that the internal log where user plaintext passwords were accidentally logged was found in an obscure place, and it's believed that the likelihood of someone finding it was low.

Link

An obscure place, except for the programming staff.

Man, many miss the flow. A log of password hash keys are a record in the logging database as well, which runs on the same permissions as the person performing the dump. This is a permissions/user/group/ACL debacle and they can spin this pokemon any way they want to, and the correct verdict of "Management Errror." will not wind up on the result list.

I can't change my password since they've suspended all my accoaunts. It's a left wing safe space

You know for some, and this directly targets the "computer know it all's" that the MSM employ to keep them inculpable, the diatribe that comes out of their respective mouths is the same stupid crap that we all used as to explain IT minutiae that the public would never understand. We live in a system where bull# has a reasonable chance to produce non-incriminating bull#. This is probably the crux of AI.

On registration / input best practices demand that if you are storing passwords then they must be hashed (not encrypted, as that is in theory reversible) .

If passwords were being logged in plain text, they likely were being logged as users typed them and submitted them for authentication.

During this process you hash the user submitted string using the same algorithm and compare it to what you have.

User input could have been logged before the hashing point.

a reply to: xuenchen

So no encryption. Sheesh.

Encryption is not used. A hash is one way so the hash cannot be reversed to yield the plain text. The plain text password is always reentered, hashed again and the hash is compared to the stored hash.

We can be almost be assured that whatever processing went on that caused the issue will never be revealed.