61–70 of 490 posts
The "right" way to handle this is to revoke access to all logged-in devices, revoke all previous passwords, send an email notifying users of the revocations, and force a password change upon next login. But Twitter won't do that because a non-trivial percentage of their user base would never jump through the hoops to get things up and running again and Twitter's MAU numbers would sink.
They don't say what the timeframe for this issue is. Have passwords been logged for the last 6 months? Last 3 years? Was this a bug found and fixed last year, and only now are they reporting it?
> that they were exposed for “several months.”
Actual twitter post: https://blog.twitter.com/official/en_us/topics/company/2018/... "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." Exact same thing that github did just recently.
"[We] are implementing plans to prevent this bug from happening again" sure makes it sound like this bug is still happening. Should we wait a couple of days before changing passwords? Will it end up in this log right now, just like the old one?
They don't say what the timeframe for this issue is. Have passwords been logged for the last 6 months? Last 3 years? Was this a bug found and fixed last year, and only now are they reporting it?
The article does say: > that they were exposed for “several months.”
I wonder what library was used, and which other companies use it which hasn't told their users. That'd let us know who isn't as transparent...
We need a regulatory rulebook codified in law by congress that fines companies that make these "mistakes". Enough of a fine will force companies to take these "mistakes" seriously. In Yahoo's case, that might have forced Marissa to actually keep a cybersecurity team and not cut them when she knew the systems were in danger of being compromised. We aren't getting any jail time, but hefty fines that don't stifle growth…
For example, I can imagine kneejerk legislation that would simply ensure that next time this happens, Twitter just keeps their lips zipped. Not exactly an improvement.
Can you pitch an example of what this legislation would actually look like? And how it would differentiate between something like the Experian leak and some (oh no) Twitter passwords getting logged internally.
Twitter's CTO had an odd tweet about this disclosure (emphasis mine): > 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. https://twitter.com/paraga/status/992135139994943488
Actual twitter post: https://blog.twitter.com/official/en_us/topics/company/2018/... "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." Exact same thing that github did just recently.
Earlier quoted context omitted.
I'm curious if anyone has details on using bcrypt/scrypt at scale. Specifically one way I could see this happening is something like login requests go to a load balancer that puts the requests on a queue to be picked up and validated by some hasher service, and the queue ends up writing the requests to logs to recover from certain kinds of failures.
Is it insecure to bcrypt/scrypt on the client instead so the server never sees the plaintext password?
The "right" way to handle this is to revoke access to all logged-in devices, revoke all previous passwords, send an email notifying users of the revocations, and force a password change upon next login. But Twitter won't do that because a non-trivial percentage of their user base would never jump through the hoops to get things up and running again and Twitter's MAU numbers would sink.
Are Github & Twitter using the same logging tools/service? Btw, Happy World Password Day!
Hashing doesn't help much when you're logging everything first.