Cloudflare Data Breach that may affect Saving Stream

I do not think that this issue affects the Saving Stream site. For any memory leak to occur, a specific set of circumstances is required, key aspects of which are unlikely to apply to the SS website.

Blue text is from the Cloudflare blog, my comments are in green:

In order for the memory to leak the following had to be true:

The final buffer containing data had to finish with a malformed script or img tag - Cloudflare reckon 0.06% of sites have HTML ending with such broken tags; the selection of SS pages I have viewed as HTML certainly do not have these issues
The buffer had to be less than 4k in length (otherwise NGINX would crash)
The customer had to either have Email Obfuscation enabled (because it uses both the old and new parsers as we transition) - unlikely, no reason for SS to enable this,
… or Automatic HTTPS Rewrites (unlikely, not widely used)/Server Side Excludes (which use the new parser) in combination with another Cloudflare feature that uses the old parser. … and Server-Side Excludes only execute if the client IP has a poor reputation (i.e. it does not work for most visitors).

That explains why the buffer overrun resulting in a leak of memory occurred so infrequently.

Additionally, the Email Obfuscation feature (which uses both parsers and would have enabled the bug to happen on the most Cloudflare sites) was only enabled on February 13 (four days before Tavis’ report).

The three features implicated were rolled out as follows. The earliest date memory could have leaked is 2016-09-22.

2016-09-22 Automatic HTTP Rewrites enabled
2017-01-30 Server-Side Excludes migrated to new parser
2017-02-13 Email Obfuscation partially migrated to new parser
2017-02-18 Google reports problem to Cloudflare and leak is stopped

The greatest potential impact occurred for four days starting on February 13 because Automatic HTTP Rewrites wasn’t widely used and Server-Side Excludes only activate for malicious IP addresses.

Furthermore, when a memory leak occurs, it is a matter of chance what data is actually leaked; it will depend on the implementation details of the web service. Often the leaked data is of no importance. Only occasionally will the leaked data contain 'useful' information such as some detail about a user.

People often wonder if they should you change their password. This depends upon whether your password can be leaked. Most sites do not store your password and therefore cannot leak it (*). What they store is a coded form and the coding system 'one-way' so that, given the coded form, you cannot (without a lot of time) recover the original password. When you enter your password, the coding is applied and the result is checked against the stored coded form. This is why most sites will not tell you your forgotten password (they cannot because don't know it); instead they will send you a new temporary password and ask you to change it immediately to something of your own choosing.

* Of course, the password is transmitted when you enter it but this should always be done securely.