5 ms·
The Tweet from the Twitter CTO on this: https://twitter.com/paraga/status/992135139994943488 https://twitter.com/paraga/status/992135139994943488 "We are shari
by jwilliams 8y ago
The Tweet from the Twitter CTO on this:
https://twitter.com/paraga/status/992135139994943488 https://twitter.com/paraga/status/992135139994943488
"We are sharing this information to help people make an informed decision about their account security. We didn’t have to, but believe it’s the right thing to do."
The "we didn't have to" is a little jarring given the scale of this.
- bomb199 8y agoWell, nothing ever left Twitter's servers. The logs themselves would probably be uninteresting to outside parties and inaccessible.
- deleted 8y ago[deleted]
- deleted 8y ago[deleted]
- colemickens 8y agoI suspect that many more employees at Twitter have access to the logs, than have access to a super computer and pasword hashes. I know I wouldn't trust my password with the number of people that have easy access to logs at other large(ish) tech companies. I really can't imagine why "we didn't have to" was included in that tweet, at all. What other flaps like this have occurred that exposed my creds or personal data to large numbers of employees, that they didn't have and didn't choose to tell us about?
- cbhl 8y agoEven if true, best practice is to strictly restrict access to and create audit trails for reading raw logs from production. Ideally, you'd only need to read raw logs tied to a test account, or, maybe your own personal accounts. Stack traces and exceptions and the like can be anonymized and collated.
- tptacek 8y agoMore employees at virtually every major web company have access to instances (and thus instance memory) than have access to supercomputer clusters, too. Every mainstream popular web application is fed a constant high-volume feed of plaintext passwords, right there in memory (or, in typical TLS termination environments, on the wire) to be read by a persistent attacker.
- colemickens 8y agoThat's true for nearly every single internet facing service, no? A compromise resulting in point-in-time access to traffic is a bit different than a bug that creates a persisted historical record of every single user who signed in for a period. Maybe I miss the point behind this comparison? I guess I'd understand more if I thought the number of folks with node access and log access were in the same magnitude at Twitter, or if the TLS stack persisted data over time.
- natch 8y ago>Well, nothing ever left Twitter's servers. Nothing is known to have ever left Twitter's servers. FTFY.
- MBCook 8y agoLast year a contractor deleted the president’s account. The fact it didn’t leave Twitter doesn’t mean everything is good. There are still a LOT of people who may have had some kind of access to this data.
- Alex3917 8y ago> Last year a contractor deleted the president’s account. The fact that they undeleted it is strong evidence that he didn't have discretion in how he performed his job, and thus was actually an employee and not a contractor.
- lstamour 8y agoI’m not sure how that follows. Are you suggesting they don’t keep backups or use a “deletion” flag temporarily, e.g. as part of spam account removal?
- SmellyGeekBoy 8y agoIndeed. I deleted my Twitter account recently, there was a message that data is retained for 30 days to facilitate un-deletion. I assume their internal process is the same.
- gowld 8y agoIf my gardener leaves a rake on my driveway, I'll remove the rake. That doesn't make the gardener an employee.
- deleted 8y ago[deleted]
- imdsm 8y agoAssuming everyone has access to the logs.
- deleted 8y ago[deleted]
- chipperyman573 8y ago>The "we didn't have to" is a little jarring given the scale of this. How come? I interpreted it to mean that no regulations required this, but they chose to anyway. Which is true.
- rdiddly 8y agoIt's kind of like pre-emptively defending yourself against an accusation that hasn't been made yet.
- alorimer 8y agoRegardless, it seems very defensive. A company that looks after their users "because they choose to" is a lot more suspicious than one where customer care is simply assumed to be inherent to the operation.
- madeofpalk 8y agoSo Twitter found out they had a bug that caused them to store passwords in one of their databases in plaintext. Their response is just a generic 'hey maybe you want to store your password'. Compare that to Github who just yesterday went through the exact same problem, except they're requiring users change their password. Their CTO didn't make some 'hey you should THANK US" claim.
- wool_gather 8y agoAre they? I just signed in on a machine where I had signed out and got no prompt to change it. Is it only certain users?
- madeofpalk 8y agoYup. Affected users were emailed 24 hours ago. Only affected people who initiated a password reset previously (I assume during a certain time frame?) > 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.