<source id="3oodw" ><sup id="3oodw" ></sup></source>

      1. <s id="3oodw" ><th id="3oodw" ><small id="3oodw" ></small></th></s>
        <i id="3oodw" ><optgroup id="3oodw" ></optgroup></i>

            <input id="3oodw" ><bdo id="3oodw" ><cite id="3oodw" ></cite></bdo></input>
            <delect id="3oodw" ><ruby id="3oodw" ></ruby></delect>

            <em id="3oodw" ><progress id="3oodw" ></progress></em><input id="3oodw" ></input>
            <strike id="3oodw" ></strike>

            CloudBleed: On Which Sites Do I Need to Change My Passwords?

            CloudBleed: On Which Sites Do I Need to Change My Passwords?

            Blog Categories: 
            CloudBleed logo

            Bloody Friday

            Most of those in the development community that their attempts to secure their websites actually left them vulnerable to attack. Beloved typically heralded as a method to shield websites from attack revealed it had a serious bug that leaked memory from "protected" sites that could reveal client IP addresses (one of the big security selling points of CloudFlare), private information, authentication tokens, cookies, passwords, private keys...basically everything that would keep a web developer up at night. CloudFlare stated in a yesterday:

            The greatest period of impact was from February 13 and February 18 with around 1 in every 3,300,000 HTTP requests through Cloudflare potentially resulting in memory leakage (that’s about 0.00003% of requests).

            However, it could have been leaking information as long ago as September 22, 2016.

            What should I do?

            The general recommendation has been to , private keys on affected servers, etc.

            Change all the passwords!

            Holy Mother of Pearl. I have over 1100 password logins in my password manager, numerous clients sites on half a dozen servers. Changing this information to be "better safe than sorry" could be a full time job for the next week even if I could ignore all other responsibilities.

            Joseph Steinberg told people not to change their passwords though on : "the current risk is much smaller than the price to be paid in increased 'cybersecurity fatigue' leading to much bigger problems in the future."

            So how can I sanely balance my risk factor with the weight of responsibility? I guess the first step is to really find out which of my sites has been affected. Once you know this, you can take more reasonable efforts.

            Which sites that I have accounts on were affected?

            released a "" containing 4,287,625 possibly affected domains based on a scrape of Alexa showing sites that used CloudFlare as their listed Name Server. So what I need to do is compare my list of 1100+ logins against this list to find which sites I need to even worry about (besides my own client sites on which I use CloudFlare). Nick offers some advice on how to do this by individually greping suspected domain names against his list. But this would be too slow and inefficient to run against all the sites I have accounts on.

            Like many web devs, I use a password manager-- by . One of its features is that you can export your passwords and logins. But it also allows you to pick and choose which fields to export. So I exported a .txt file that contained only the login URLs I had stored and named it 1pw-login-urls.txt:

            Exporting login urls as a .txt file with 1Password.

            This list is great but it's formatted for data import with double quotes around the login urls and the urls themselves have paths that would have to be cleaned up to do an apples-to-apples domain comparison against Nick's list. Running the following in a Mac or Linux bash terminal cleans it up sufficiently to do a comparison and outputs just the domains by themselves in the file ~/Documents/1pw-domains.txt:

            sed -e 's|^[^/]*//||' -e 's|^www\.||' -e 's|/.*$||' -e 's/\"//g' ~/Desktop/1pw-login-urls.txt > ~/Documents/1pw-domains.txt

            After that, I run the following to do the comparison between my 1pw-domains.txt list and Nick's sorted_unique_cf.txt list to get a list of the sites that I might want to consider resetting the passwords on and store those in a new file named password-reset-sites.txt:

            comm -12 <( sort ~/Documents/1pw-domains.txt ) <( sort sorted_unique_cf.txt) > ~/Documents/password-reset-sites.txt

            Happily, instead of having to look through 4M+ listed domains or even 1100+ domains, I find myself looking at a list of only 11 sites that I need to consider actions on! Yay! That luckily being the case, I can easily assess the potential risks, act accordingly, and instead of spending a horrible week resetting passwords, I can enjoy the rest of my Saturday playing Assassin's Creed.

            I hope you find this helpful and may your own weekend be as pleasant.

            Requiescat in pace, CloudBleed.

            Home page Disclaimer: This website's materials and pictures are sourced from Internet articles. This website does not bear any claims and legal liabilities caused by content information. The copyright of all works belongs to the original author, and has nothing to do with this previous field. If users accidentally infringe your rights and interests, please contact us and we will delete it!

            <option id="lrq7b" ><sup id="lrq7b" ></sup></option>
            <noscript id="lrq7b" ><nobr id="lrq7b" ><label id="lrq7b" ></label></nobr></noscript>
            1. <em id="lrq7b" ></em>
              <div id="lrq7b" ><optgroup id="lrq7b" ></optgroup></div>
              <dfn id="lrq7b" ></dfn>

                <u id="lrq7b" ></u>