Google Chrome’s DNS Fucked Up, What Do?

Google Chrome's domain does not exist error page.

Google Chrome on my laptop randomly decided my blog’s domain doesn’t exist. Except, it clearly does. Searching for a solution tells me to do everything from restarting the computer to deleting all browser history – which should be obviously wrong, not to mention annoying. Here’s the laziest quickest way I solved it:

Google Chrome's net-internals' DNS page.
Step 1: Clear host cache.
  1. Go to chrome://net-internals/#dns and click “Clear host cache”
  2. That didn’t work.
  3. Go to chrome://settings/security and use a different secure DNS provider from the default
Google Chrome's security settings page.
Step 3: Use an actually secure DNS provideer.

Considering Google decided to be evil (notice those are 3 separate links) and does the same mass data hervesting and privacy violations as every other big tech company, we shouldn’t be using anything they touch. However, the least we can do and still have a compatible browser is to stop using their “secure” DNS provider anyhow..

Backup Solutions

The following is current as of May 2019:

I’ve spent a few days researching software and services for backing up data. My requirements: encrypted backups, deduplication, low cost, compatible with Windows 10 & Linux, and preferably using off-site storage.

Software

I have only considered two competitors: tarsnap and restic. Tarsnap can create keys with different permissions – a server can run backups with no danger of a compromise leading to the destruction of backups, but it is only compatible with tarsnap.com for data storage.

Restic allows you to plug it into any system for storage. I prefer tarsnap’s extra layer of paranoia, but the service costs are where the battle ends for me.

Update: These tools both deduplicate at a block size rather than by file, and both utilize a cache for speeding up backups. Both chunk at a dynamic level, with data blobs/chunks/blocks usually being around 1MB. Tarsnap’s cache is local, but can be restored by scanning the backup server (at a network usage cost of approximately 0.1% the size of the data stored), while restic uses both a local cache and a cache on the destination. Restic also creates checkpoints while uploading backups to reduce duplication caused by interrupted uploads.

Services

  • Tarsnap: $0.25/GB/month (transfer: $0.25/GB)
  • Rsync.net: $0.04/GB/month (min: 200 GB)
  • Amazon S3: f***ing complicated pricing
  • Wasabi: $0.0059/GB/month (no other charges)
  • Backblaze B2: $0.005/GB/month (download: $0.01/GB)
  • Local: Hardware costs + electricity.

Obviously, price is not everything. Rsync.net offers daily snapshots, cheaper per-GB pricing with mass amounts of data storage needed, and additional features. Amazon S3 and Wasabi are designed for application services rather than storage. Backblaze’s B2 is probably the only cloud service (of those I examined) designed for this usage.

Ultimately, cost is my limiting factor. My backups are using restic and local hardware for now, but I plan to move to using Backblaze B2 as I can afford to.

Updates

Since publication, a few have reached out to me recommending alternative services or sharing their choices. I have not compared these as thoroughly as I did my shortlist, but I feel they deserve their own note for anyone pursuing this decision themselves:

  • SpiderOak One Backup: Starts at $0.04/GB for their 150GB plan, goes down to $0.0058/GB with a 5TB plan. I’d probably choose it if I had a bit more money to spend.
  • CrashPlan for Small Business: $10/computer, “unlimited” storage. Haven’t looked at the caveats included.

(Note: All resources are archived using the services linked to on Archives & Sources. In this case, that is only relevant for comparison from the past.. oh well!)

Password Security 2.0

(This post has been imported from an old blog of mine, and updated March 2018. It is November 2021 at the time of this edit, and this information is still accurate, up to date, and relevant.)

I made a post a while back about how to check if a user’s password is secure from the programmer’s perspective, but looking at it now, I realized I don’t cover a key concept, and I’ve learned about an additional measure that I really should have had on the list.

How to store passwords?

The number 1 most important thing to do is to NEVER store passwords. Instead, you use an algorithm to store a hash generated from a password. Why? In case you get hacked. If your database is downloaded, and it has user passwords, even if you repair any damage or stop the hack, the passwords are out there! But if you use hashes instead, they can’t be used to login.

How you hash matters though. If you use something like MD5, that’s trivial to crack these days. SHA-1 is a bit more secure, but still has been destroyed in usefulness for security. Which algorithm(s) should you be using?

  1. bcrypt: The current de-facto algorithm for password hashing. It can be changed the strength of the algorithm to create stronger hashes even if computers get faster.
  2. scrypt: Builds upon bcrypt by focusing on calculations that are harder to do on specialized hardware. It also can be changed to create stronger hashes, but the factor used to do this is exponential.
  3. Argon2*: Won the Password Hashing Competition in 2015**, the only reason it’s not on the top of this list is that it is relatively new and not as proven as scrypt/bcrypt. (The biggest weakness with bcrypt at the moment is that it can be relatively effectively attacked with GPUs/FPGAs/ASICs, which scrypt and Argon2 protect against by increasing how much memory is required to compute a password hash.)
  4. PBKDF2: Wasn’t actually intended to be used for security, but is rather slow, which makes for a good hash algorithm. (A big part of hash security is using a slow algorithm.)

It is most often recommended to use bcrypt as it is the most tested and known secure algorithm. It will probably be replaced by scrypt when scrypt has been more thoroughly tested and if vulnerabilities are found in bcrypt. PBKDF2 should really only be used if for some reason you can’t use the other two. If you want to use something else, don’t.

* Was added in March 2018 after some further research into the subject.
** I found a couple of sources claiming it was in 2015, but also one that said 2013. I’m not sure which is correct.

What kind of passwords should be allowed?

This was the whole point of the other post, and the first three items are almost identical:

  1. Must not contain more than 6 occurrences of the same character.
  2. Must be at least 12 characters long.
  3. Must not be equal to or contain your username, your email address, the site’s name, the site’s URL, and associated keywords (like, your actual name on sites that store that info; or “Honda” on a motorcycle forum).
  4. Must not be equal to the 10,000* most common passwords.

The change is to say you should have 12 character or longer passwords, and the addition is checking against the most commonly used passwords. The first measure is because computers are always getting better at cracking passwords, and cheaper. The second is because the first two rules don’t completely stop you from using commonly known passwords like password1234567890 or qwertyuiop1234.

* I say 10,000, but the list really should be just whatever most common passwords list you can get. This is something I need to research further myself.

Sources and Further Reading

These primarily relate to Argon2 since that is what I most recently researched when editing this post. (Note: All resources are archived using the services linked to on Archives & Sources.)

  1. Password Hashing Competition
  2. An brief explanation of results from PHC & notes about attacks against Argon2. (This was another reason I put it lower on the list, though I am not a cryptography expert, so this could be unjustified.)
  3. Several comparisons and discussion about configuring these algorithms correctly.
  4. A bit of arguing and discussion about bcrypt and PBKDF2.
  5. More discussion about Argon2.
  6. libsodium is a library for doing cryptography that I would trust with this kind of thing. I haven’t looked too much at it myself, but I pass the recommendation along from experts I trust.

How to Check for Password Security

(This post has been imported from an old blog of mine, and superseded by a more recent post.)

It’s actually not that complicated to do right. But there are a lot of websites that don’t do it right. To put it simply:

XKCD #936: “Password Strength” demonstrates common security practices, their flaws, and a more secure password format. Ironically, the example password is now seen in hacked database dumps, as people don’t realize a popular webcomic’s demonstration is fairly easy to guess.

Or, a wordier form: You see lots of sites banning special characters, requiring an uppercase and lowercase character, and one number, or some variation of that and with more and more specific rules. The problem with these rules is that they make passwords hard for people to remember without really increasing security, punish users using secure passwords that don’t happen to quite match the requirements, and lead to people trying to figure out ways to get around them that lead to less security.

Not to mention, by forcing passwords into such specific rules, you’re giving a potential hacker more information about how to make guesses, because every password is going to match these rules. The more specific they are, the less has to be checked. For example, if every password must have a number, well then you don’t need to check any words by themselves, just words with numbers added on or mixed in. If special characters aren’t allowed, that’s millions of combinations that don’t need to be checked anymore.

So how do we make more secure passwords?

Three simple rules:

  1. Must not contain more than 6 occurrences of the same character.
  2. Must be at least 10 characters long.
  3. Must not be equal to your username, your email address, the site’s name, the site’s URL.

And with that, you have stopped the majority of bad passwords. There’s only one thing left to do… This list will not always be true, in the future, longer passwords will probably be needed. The whole reason I’m even saying 10 characters is because 8 character passwords are essentially equal to not having a password at all these days. I personally use 32 characters or more, because that will last a while, 10 characters is a lot closer to becoming easily hackable.