71–80 of 490 posts
So why are they not invalidating exposed passwords like Github did the other day? At the very least they should have a security alert at the top of your feed or something. Edit: Looks like they are alerting users.
Earlier quoted context omitted.
Well, nothing ever left Twitter's servers. The logs themselves would probably be uninteresting to outside parties and inaccessible.
I 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 t…
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.
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…
Why? I have a small app with a few thousand users that generate almost no money but contain sensitive data - if I were to be fine because of a leak, I would be dead financially. Where do you draw the line between the companies that should be fine and those which don't? No matter how advance our technology is or the security measures we take, any system connected to internet somehow will have a leak or an intrusion or…
must be the same logging library/framework as github. I want to know which library it is.
The Tweet from the Twitter CTO on this: 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.
I haven't actively logged into twitter in almost a year. Does this affect me?
These comments are everything from eliminating passwords (good luck) to “congress should fix it with law” (lol). Having been in the identity space for a while and seen how various companies think about it, these kinds of problems will keep coming up...mostly at companies for whom identity is commodity. These companies will always give account security the minimum requisite attention. No one at Twitter gets excited ab…
For the average person (not worried about a megacorp or nation state attacking them), TouchID is also a possible "password replacement" for the primary authentication factor, although it comes with the disadvantage of not being rotatable.
1. Make a list of all sensitive information that the test users in your test environment will be giving to your application.
As part of your test procedure, search all logs for that information. This can be as simple as having a text file with all the sensitive information, and doing a 'grep -F -f sensitive.txt' on all your log files.
2. If you are working in some sort of object oriented language, make separate classes for sensitive data, such as a class Password to hold passwords, a class CardNum to hold credit card numbers, and so on.
Make the method that whatever you use for logging uses to convert objects to strings return a placeholder string for these objects, such as "Password", "Credit Card Number", and so on.
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?
From the authorization side, there is a threat, because if your table storing hashes is compromised, attackers just have to supply the stored hash to the auth endpoint and they get to login as anyone.
A combination of hashing on the client side (or immediately once the pw hits the endpoint) with something cheaper followed by a more intense bcrypt/scrypt afterwards might help a bit with the tradeoffs.