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 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..

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.

  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.