I've just got a brand new cellphone. The first thing I do, is factory reset the device, because it came with the setup steps already finished, not to my liking. All goes well of me refusing as many things as I can while still being able to actually use the phone, until I get to the "protection" page. Facial recognition and fingerprint scanning. Eww. I, of course, choose to go with password protection. The phone greets me by saying that the password must contain at least four characters, and must at least have one letter. Having done this before, I start rapidly pressing the 'h' key, to discover that the phone does, in fact, have a secret upper limit of 16 characters.
So, we have an upper limit of 16 characters and a lower limit of 4, and we're required to use one of those characters as a letter. I can express this as:
16 >= X >= 4, 1letter
This doesn't say a whole lot just yet. So, I counted up all the characters on the keyboard, tested them and luckily, they all seem to be valid for passwords. I counted 92 characters as part of the charset. Let's think about the basics of statistics.
Bits of Data
When rolling a die, it may land on any of its 6 sides. If a roll two, they individually may land on any of their six sides but there are a total of 36 different combinations they make up. Notice how the fractions multiply together. The numerators both multiply to make the new numerator and the two denominators multiply together to make the new denominator.
(1/6) * (1/6) = 1/36
The reciprocal of each fraction gives us the total number of possibilities for each event. If I wanted to calculate the total number of combinations possible for my password, I could express it as such:
92 of the 15 characters can be anywhere in the charset, but one of the chars must be a letter. The result is quite a huge number, and while we may assume that this must allow us to have all sorts of great passwords, we should take a step back and put that huge number in a form that we can understand:
ln( (92^15)*26 )/ln(2) ~= 102.6
The number that we have gotten from the equation above, is the number X where X would be the number that gives us the same number of combinations if we were just calculating 2^X. So what I'm trying to say, is:
(92^15)*26 ~= 2^102.6
By measuring possibilities in terms of X, we can actually try to wrap our heads around what those big numbers mean. By doing this, we're measuring possibilities as bits of data. Bits meaning binary digits. The thing is, every time we increase our number of bits by one, we multiply the total number of possibilities by two. Which means that, an increase of one bit when we had few bits to begin with, the change in the total number of possibilities is small but, if we increase by one bit and we have a lot of bits to begin with, the total jump in possibilities can be substantial.
Bits of entropy
Now, you may have thought about the security of using the password "password". If our charset contains only letters, you may think that because it takes 37.6 bits to store that data, then it must be a decent password. This is false, because we don't measure password security in bits of data, we measure it in bits of entropy. Let me explain, bits of entropy is the measurement of randomness, and randomness is defined by its unpredictability. Sadly, humans are hardly random, and "password" is one of the most commonly used passwords.
The Real World
We know how to measure password security, but how secure should a password be? For that, we have to look at our given situation. I'm picking a password for a dumb cell phone, but I want to pick one that wont be breakable for as long as I have it, which will be about three years until I get a new one. Of course, I'll still have this one, but if I get a different phone as a daily driver in the future, I'll wipe my current one and try to port an alternative OS to it, like one of the Android clones or PostmarketOS. So, how do you pick a password that's going to last? Especially against an entity who would do anything for your password? For that, we must look towards the real world, and fantasize. The biggest computing entity that performs the most cryptographic operations per second known to any layperson is the blockchain. Let's imagine they're out to get us. Using information from blockchainstats.org, as of June 2019:
Hash rate: 64,456,566,031.52 GH/s Revenue: 25,391,962.28 USD (last 24hrs of mining)
This says a lot. Let's pretend that the blockchain has our phone, has made as many duplicates as it likes, and the hash rate is equal to the number of tries it can attempt in a period of time:
64,456,566,031.5210^9 = 6.44565660315210^19 c/s 189216000s (2statistic const, 3 years365d/y24h/d60m/h60s/m) 6.44565660315210^19c/s * 189216000s = possibilities we want, X
ln(X)/ln(2) ~= 93.3 ideal bits of entropy.
The 2 in the statistical constant is there because, say, if you're searching through a deck of cards for the ace of spades, and the ace could be anywhere in that deck, it'll take you on average half the time it could take you to search the entire deck until the end. Doubling the length of time ensures that the average amount of time it takes to find the password is how long we want it to take, rather than half.
What password do we pick?
Due to the fact that the phone only allows 102.6 bits of entropy, which is enough to fit our 93.3, we wont be able to pick a memorable password. Let's use the X variable from the previous section (2^93.3). Our charset consists of 92 characters, so to know how many characters we need minimum, we do:
ln(X)/ln(92) = 14.3
We round up the result to 15. We need a completely random password, 15 characters in length with either no 16th character or a predictable one. How lame. Consider this lesson as to why upper limits on password lengths actually harm password security, by limiting not only ones ability to create entropy, but ones ability to create secure passwords that are memorable.
Creating memorable secure passwords
Let's pretend that my poor cell phone has no upper limits. I can pick a password of any length I want. Please ignore the cheesy name, but diceware is a nice easy way of doing this. The Electronic Fronteir Foundation has published its own diceware lists, which I highly recommend using. First, we calculate how many dicerolls are needed in order to create a secure password.
ln(X)/ln(6) = 36.09
We always round these numbers to the nearest integer. 37 is how many we need. If we're using the long word list (reccomended) with five dice rolls per word, that would mean that we need 40 dicerolls total, for 8 words. If using the shorter list with four dice rolls per word, that's still 40 rolls, but making 10 words. Let's generate a sequence using real dice! The advantage is that you don't need to worry about a faulty RNG or a compromized computer. Just make sure that your cell phone or other devices aren't watching:
22536,56615,33442,42434,42264,31641,21253,52134 delirium stubbly hardcover olympics nutshell game cradling reverse
2253,6566,1533,4424,2434,4226,4316,4121,2535,2134 dart wired cedar perm drive mule oil lurch elope cot
Please don't copy the above passwords and use it yourself. If someone knows you've read this, they might know to try the above passwords first.