"The company said that the bug affected less than 1 percent of users on Twitter. The company had 335 million users as of its latest earnings release."
So the bug affected roughly 3.3 million Twitter accounts. And it also affected everyone who may be impacted by the contents of the messages which were not protected, whether you're a Twitter user or not, which could be many millions more.
"Less than 1" != 1. The bug affected roughly 3.3 million at most. It is annoying that they don't give more precise number, but I doubt most people would care.
The article was submitted with a title matching the TechCrunch title at the time of submission. TechCrunch changed their title after it was submitted to Hacker News.
Maybe you could just link to the Twitter blog and get it over with. Stop giving TechCrunch a pass for blog spam while you replace links for all other sites.
"Twitter said in a notice that only messages sent to brand accounts — like airlines or delivery services — may be affected"
I hope this is true. I got the message and only really use twitter DMs for communicating with banks and airlines.
The message itself seems really poorly worded to me - I assumed that one of their APIs didn't check permissions and included all DMs and protected tweets in its output. "one or more" makes me assume "all" and "may" usually means "definitely has" in these kind of messages so it would have been great if they had included details about potential mitigating factors.
Not saying it's good, but a lot better than it originally sounded. The two domains pointing to the same IP is pretty rare. The place that got the sensitive information is used to dealing with it anyway (ie maybe AirFrance can read personal information that I sent to the post office - they will both hopefully have their own policies on dealing with such information).
With these details I think any personal information I included in DMs is less likely to be used maliciously through this bug than e.g. from someone accessing my twitter account directly or through a malicious actor at the Brand Account I intended to share with.
The worst one was at the bottom, who cares about DM -
"Twitter also said that earlier this year there was a bug where log files where created with user passwords in plaintext. Twitter urges users to change their passwords"
I mean, what type of company with over a billion dollars in VC capital stores passwords in plaintext?
It's very unlikely they store their passwords in plaintext. They were probably logging during login requests and didn't realize the whole request body was being logged. Can happen if you have a proxy/load balancer with logging enabled.
I don't think they were storing them in plain text, but on a login request it would log the request body without properly censoring the password. The password could still be hashed when it was actually put into the database.
That's almost certainly a case where POST parameters get logshipped to some server for debugging purposes, and it's easy to miss something like that in an audit when you're dealing with terabytes of logfiles.
Even if the logfiles are rotated every day you don't know if a developer has seen somebody's password during that window, so all passwords are assumed to be compromised.
If it's not end to end encrypted via a free software, audited client, you should be operating under the assumption that it is not being held in confidence.
In this day and age, you shouldn't settle for anything less.
That means I should assume 100% of my emails are not confidential, which is an impossible situation for most people with jobs and non-technical relatives.
We have validated that this bug might have occurred when all of the following technical circumstances were true during the relevant time period for this issue:
🞄 Two or more registered developers had active Account Activity API subscriptions configured for domains that resolved to the same public IP;
🞄 Those registered developers had activity relevant to their subscriptions occur in the same 6-minute time period (relevant because of a cache-like behavior); and
🞄 Those registered developers’ subscribers’ activities originated from the same backend server from within Twitter’s datacenter
Under those circumstances, if the bug occurred, the issue (transmission of activities to the wrong webhook URL) could have persisted until one of the following conditions were met:
🞄 For up to two weeks, OR
🞄 Until no relevant activity occurred for 6 minutes, OR
🞄 Until the IP address of the developer whose data was being misdelivered changed
26 comments
[ 3.1 ms ] story [ 63.5 ms ] threadSo the bug affected roughly 3.3 million Twitter accounts. And it also affected everyone who may be impacted by the contents of the messages which were not protected, whether you're a Twitter user or not, which could be many millions more.
Also:
>a “bug” sent user’s private direct messages to third-party developers “who were not authorized to receive them.”
But:
>it’s “highly unlikely” that any communication was sent to the incorrect developers at all
Which one is it?
I hope this is true. I got the message and only really use twitter DMs for communicating with banks and airlines.
The message itself seems really poorly worded to me - I assumed that one of their APIs didn't check permissions and included all DMs and protected tweets in its output. "one or more" makes me assume "all" and "may" usually means "definitely has" in these kind of messages so it would have been great if they had included details about potential mitigating factors.
https://blog.twitter.com/developer/en_us/topics/tools/2018/d...
I'm not trying to downplay this, but I'm also not sending United Airlines my innermost secrets here...
I'm going out on a limb here and say the average hackernews user is not the average twitter user :)
http://twitter.com/NeedADebitCard
With these details I think any personal information I included in DMs is less likely to be used maliciously through this bug than e.g. from someone accessing my twitter account directly or through a malicious actor at the Brand Account I intended to share with.
"Twitter also said that earlier this year there was a bug where log files where created with user passwords in plaintext. Twitter urges users to change their passwords"
I mean, what type of company with over a billion dollars in VC capital stores passwords in plaintext?
Even if the logfiles are rotated every day you don't know if a developer has seen somebody's password during that window, so all passwords are assumed to be compromised.
> May 3, 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.
> — https://blog.twitter.com/official/en_us/topics/company/2018/...
In this day and age, you shouldn't settle for anything less.
Likely via regulation. Possibly by lawsuit.
user's -> users'
__plural__
We have validated that this bug might have occurred when all of the following technical circumstances were true during the relevant time period for this issue:
🞄 Two or more registered developers had active Account Activity API subscriptions configured for domains that resolved to the same public IP;
🞄 For active subscriptions, URL paths (after the domain) had to match exactly across those registered developers -- e.g. https://example.com/[webhooks/twitter] and https://anotherexample.com/[webhooks/ twitter ];
🞄 Those registered developers had activity relevant to their subscriptions occur in the same 6-minute time period (relevant because of a cache-like behavior); and
🞄 Those registered developers’ subscribers’ activities originated from the same backend server from within Twitter’s datacenter
Under those circumstances, if the bug occurred, the issue (transmission of activities to the wrong webhook URL) could have persisted until one of the following conditions were met:
🞄 For up to two weeks, OR
🞄 Until no relevant activity occurred for 6 minutes, OR
🞄 Until the IP address of the developer whose data was being misdelivered changed