61–70 of 228 posts
That list isn't that useful... First of all, there is a LOT of pages hosted by CloudFlare @taviso acknowledged that in the original bug report. ( https://bugs.chromium.org/p/project-zero/issues/detail?id=11... ) Furthermore, you can't say which sites were hit by this bug and simply listing all CloudFlare sites is more or less fearmongering. If you are a verified victim of this bug CloudFlare will contact you. Lastly,…
I wrote this(1) script to check for any affected sites from local Chrome history. It checks for the header `cf-ray` in the response headers from the domain. It is not an exhaustive list but I was able to find few important ones like my bank site. 1: https://gist.github.com/kamaljoshi/2cce5f6d35cd28de8f6dbb27d...
https://gist.github.com/avian2/30db0d579732287d758c21ba8ded9...
Earlier quoted context omitted.
Inside of TLS, 1Password uses an additional SRP handshake that negotiates a static secret (like a DHE), which 1Password uses to both authenticate the user and set up an additional AES-GCM transport encryption. So even a full memory dump of what's transported in TLS should, as long as it's properly implemented, only reveal an SRP authentication session and subsequently symmetrically encrypted data. (And inside that SR…
Interesting, thanks for the reply. I wonder which password manager the original Project Zero thread referred to then if not 1Password.
What if I sign in with facebook or other? Should I change muy password con facebook or what?
Long Version.
That (most likely) would of used oauth. So instead of sending your FB password to the site to log you into FB with. You give your FB password (if your not signed in) to FB and then facebook give the site using "sign in with Facebook" a token they can use with facebook to get account info / do actions on your FB account.
Now depending on which "sign in with" system you used then often the code handed back to the site (via a callback URL handled by the client) is a single use code. So once the site using "sign in with" has used the code with FB they get another set of tokens they will use with Facebook directly.
After the initial "sign in with" process the Facebook tokens are most likely never handed to clients (because they often need to be mixed with a site secret during requests to the likes of Facebook).
So you _should_ be ok if you used a decent "sign in with" system like facebooks as the only thing that would of been handed back to the client and then sent from the client to the site is that single use code. The communication with the site and facebook would of used an API endpoint.
Now... If you used another sites (not facebook) "sign in with" system and their API is also behind Cloudflare it could well be that some API keys could be in a cache somewhere. If those requests were signed with secrets you should be fine because without the sites secrets to lets say create a hmac signature for the request then while there might be some personally identifiable information in caches somewhere the signatures should of already expired meaning that they can't be used in say a replay attack and the data cached can't be used to create fresh requests.
BUT this all depends on everyone doing things right, which may not be the case. But either way, oauth tokens are often not revoked when you change your password. I.e. you might change your FB password and then still be able to auto login on somesmallsite.org because the tokens shared between FB and somesmallsite.whatever haven't changed.
That list isn't that useful... First of all, there is a LOT of pages hosted by CloudFlare @taviso acknowledged that in the original bug report. ( https://bugs.chromium.org/p/project-zero/issues/detail?id=11... ) Furthermore, you can't say which sites were hit by this bug and simply listing all CloudFlare sites is more or less fearmongering. If you are a verified victim of this bug CloudFlare will contact you. Lastly,…
While Cloudflare might contact their customers, it's no guarantee that the customers will actually notify their users, so I think this is a good way to find out which sites I might have to change my passwords and API keys on.
I wouldn't be surprised if people receiving this took no action.
"List of Sites possibly affected" Sites using Cloudflare, really. However, Cloudflare say that only sites using three page rules were affected - email obfuscation, Server-side Excludes and Automatic HTTPS Rewrites. [1] Is this over-estimating the impact, perhaps? [1] https://blog.cloudflare.com/incident-report-on-memory-leak-c...
No! And this is why cloudfare's poor write up continues to confuse people. Sites with those features triggered the bug. Once the bug was trigerred the response would include data from ANY other cloudfare customer that happened to be in memory at the time. Meaning a request for a page with one of those features could include data from Uber or one of the many other customers that didn't use those features. So the poten…
I assume there's a separate email for sites where they happened to find Google cache data, but...
Earlier quoted context omitted.
While Cloudflare might contact their customers, it's no guarantee that the customers will actually notify their users, so I think this is a good way to find out which sites I might have to change my passwords and API keys on.
The email Cloudflare is sending out to customers where Cloudflare didn't find any cached info isn't particularly alarming: http://pastebin.com/pUnKJE3J I wouldn't be surprised if people receiving this took no action.
I think not every "leak" is sensitive, but there are definitely instances Cf and Google both found very sensitive information.