Tag: how to

Posted on

Simplified Fluid Storage System

(A flaw in the design of this system was fixed and posted about here.)

One of my game ideas involves constructing 2D spaceships, and the concept of a simplified system for storing fuel, oxygen, water – really any kind of fluid mixture – in storage tanks. Along with this, it allows simulating breaches between containers, hard vacuum, and the pressurized areas of the ship itself!

{ -- a rough approximation of Earth's atmosphere
  pressure: 1
  volume: 4.2e12 -- 4.2 billion km^3
  contents: {
    nitrogen: 0.775
    oxygen: 0.21
    argon: 0.01
    co2: 0.005
  }
}

{ -- hard vacuum
  pressure: 0
  volume: math.huge -- infinity
  -- the contents table will end up containing negative infinity of anything that leaks into the vacuum
}

It all comes down to storing a total pressure and volume per container, and a table of contents as percentages of the total mixture. The total amount of mass in the system can be easily calculated (volume * pressure), as can the amount of any item in the system ( volume * pressure * percent).

Breaches are stored as a reference in the container with a higher pressure, and a size value is added to the container with lower pressure (representing the size of the hole between them).

screenshot of testing my fluid system
A sequence of tests.

Limitations

  • Everything has the same density and mixes evenly.
  • There are no states of matter, everything is treated as a gas.
  • Attempting to directly modify the amount of a fluid is prone to floating-point errors it seems, while mixing containers via the breach mechanic is working as expected.

The code was written in MoonScript / Lua and is available here.

Updated 2024-10-11 to fix broken link.

Posted on

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

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.