Image of the glider from the Game of Life by John Conway
Skip to content

Creating Strong Passwords Without A Computer, Part III - Off The Grid

Previously, I used entropy as a backdrop for creating strong passwords. It's important that you read that article and fully understand it before moving on with the rest of the series.

So far, I've blogged about generating passwords using systems that your grandma could use. In this case, I have less confidence that my grandma would be willing to give this a go. Not because she's stupid, but because she's impatient. The older I get, the less patience I have for things like this, so I can understand where she's coming from. In this post, we'll be discussing Steve Gibson's paper cipher Off The Grid.

Introduction

Off The Grid is a paper-based cipher for encrypting domain names. The concept is built around the idea of using Latin Squares as a means for creating the cipher. Off The Grid is a 26x26 Latin Square using the English alphabet. In other words, any character appears only one in any given row and column. As a result of the Latin Square, words can be traversed throughout the square, alternating rows and columns. This will be explained further.

Outside of the grid are numbers and non-alphabetic characters. These are used as an additional resource when creating the passwords for your sites. Because the grid itself is a randomized mixture of lowercase and uppercase letters, the grid itself has an entropy of approximately 5.7-bits per character. The outer border consists of the following characters:

0123456789!"#$%&'()*+,/:;<=>?@[$$^{|}~

As such, if using the border to build your passwords, then you have access to 90 total unique characters, bringing your entropy to approximately 6.59-bits per character.

Because we determined that 80-bits of entropy should be the minimum when generating passwords, if your password consists of only the alphabetic characters in the grid, then you should aim at building at least 15-character passwords. If you are including the outer border in your password building, then a 13-character password should be the target.

The grid and border are randomized, minus 12 characters in the center of the top border, so the resulting password is a true random password that can be used for your accounts. Thus, the requirements to build a truly random password with at least 80-bits of entropy is achieved.

Off The Grid

Off The Grid is a finite state machine. This is achieved by traversing the grid from a starting location to an ending location, the rules of which will be described here. After reaching your first ending location, a second traversal is made starting from the first ending location, and ending at a new location. There are exactly 26^2 or 676 states in the Off The Grid system.

In Steve's instructions for building passwords using the grid, you take the first 6 characters of the domain name, and build a resulting password of 12 characters- 2 ciphertext characters for each 1 plaintext character. Unfortunately, as we demonstrated, this doesn't provide us with enough entropy to withstand offline database attacks. As such, I would look at what you want for your target password length. If it's 15 characters, then I would take the first 5 characters of the domain name, and use a ratio of 3:1 rather than 2:1 when building the password. If you want a 16 character password, then you could use the first 4 characters of the domain name, and use a ratio of 4:1, or you could take the first 8 characters of the domain name, and use a ration of 2:1. Keep this in mind, because from here on out, it gets challenging, and you'll need your ratio for later.

Off The Grid can be described in the following steps:

  1. You are always using the domain name for building your passwords.
  2. Determine how many characters from the domain name you will need to build your password.
  3. Find the first character of the domain name in the first row.
  4. Find the second character of the domain name in the column below the first character.
  5. Find the third character of the domain name in the row of the previous character.
  6. Alternate rows and columns until you reach the last character of the domain name.
  7. Starting at your new position, find the first character of the domain name in that row.
  8. Overshoot in that row by the ratio you determined before. If your ratio is 2:1, overshoot 2 characters. If your ratio is 4:1, overshoot 4 characters.
  9. Write down the characters you overshot with. These will build your password.
  10. Now at your new overshot position, find the second character of the domain name in the column below the overshot character.
  11. Overshoot in that column by the ratio you determined before.
  12. Write down the characters you overshot with.
  13. Continue alternating rows and columns, overshooting by your ratio, and writing down the overshot characters until you've traversed the domain name
  14. You now have your password.

PHEW!!!

Building passwords using Off The Grid is tricky. Once you understand the above steps, and practice it, then it will become easy. But the initial understanding of how the system works is a bit a pain in the behind. In the next section, I'll be providing an example.

A Simple Example

Visiting his website, I created the following sample grid that we'll use for this post:

A Sample Off The Grid key.

Suppose we wish to setup a password for example.com, and suppose that example.com does not restrict passwords for our account in anyway. As such, we are fine building passwords with just alphabetic characters. We'll handle how to add non-alphabetic characters to our password in a minute. As such, I need to build a 15-character password. The text "example" is 7 characters. I'll take the first 5 characters "examp" and use a ratio of 3:1 for building my password.

First step is to locate the letter 'e' in the first row. You can decide to use any row, or column for your first letter. However, the goal is to be consistent, as using a different row or column for the same domain will produce different results. In these examples, I'll be starting in the first row. In this example, it's in the 25th column from the left edge. Now I locate the 'x' in the 25th column. It's in the 18th row from the top in the 25th column. Now I look along that row for 'a'. I continue in this manner, until I've worked out "examp". On my example card, my path after phase 1 would look like this:

Tracing the text 'examp' on our sample OTG key.

Now I'm in a new location ready to start creating my password. This is phase 2, the overshoot phase. Because I ended looking for 'p' in the same row as 'a', I'm going to switch to looking for 'e' in the same column as 'p' to start this phase. In other words, I am constantly alternating row, column, row, column, etc., even when switching phases. However, rather than stopping at the letter 'e', I will overshoot by by 3 characters, recording the characters I have overshot.

So, I find 'e' then continue moving 3 characters in the column, reaching 'a' in my example grid. The 3 characters that were overshot were 'Mta'. These are the first 3 characters of my domain password for example.com.

I now look for 'x' in the same row as my overshot 'a'. I will again overshoot by 3 characters to the letter 'P'. The overshot characters in that row were 'zhP', and are the second set of characters for my password. Thus, up to this point, my password for example.com has become 'MtazhP'.

I will continue alternating rows and columns, overshooting by 3 characters, writing down the overshot characters as my password, until I overshot every character in "examp". My password is "MtazhPfoYgpJvWy", and my path would have looked like this in phase 2 (the domain path is traced in red, with the overshoot characters traced in blue):

Tracing the text 'examp' again, this time overshooting by 3 characters on our sample OTG key.

Notice that my overshoot needed to wrap around the card. This should be expected in phase 2, and wrapping around the card is appropriate.

Make sure that you fully understand these two phases of creating your password before continuing. You want to make sure you get it right every time for every domain, without error.

Handling non-alphabetic characters

Now it's time to get a bit ugly. Up to this point, the OTG system only generates passwords with alphabetic characters. It does not generate passwords with anything else. This can be problematic for sites that require the use of non-alphabetic characters in the password. Further, some domains may have a '.', '-' or digit as part of the domain. These non-alphabetic characters are not part of the inner OTG grid, so creating a password with them is impossible.

This is where the outer border comes into play. First notice that a digit and non-alphanumeric character are always opposite of each other on the border. This is by design. In our case, opposite of '#' on the top border is a '2' on the bottom border. Opposite of the ',' on the bottom border, is the digit '8' on the top border, and so forth. Let's first discuss how to add non-alphabetic characters to our passwords:

Letting the OTG choose

While traversing the grid in phase 2, building your password, you can incorporate the border into your overshoot. In my previous example of "example.com", we traced out the word "examp", and overshot with 3 characters, all of the form <grid><grid><grid>. Rather, we could have used our 3rd overshoot character to be our border character. As such, our pattern would have been <grid;><grid><border>. In that case, we would stop at the 2nd overshoot character, rather than the border, to find the rest of our characters in our domain. As a result, for every character in the domain, there will be a non-alphabetic character:

Sample OTG showing a possible path for building a password with non-alphabetic characters.

In this case, the password for example.com would be "Mt.bA1oQ7cZ[IA2"

This example also brings up a good point: when the overshoot character is the same character as the next character that you need to traverse to, then skip one more character. In other words, notice that with "examp", when we travel to "x", our overshoot character is "A". This is the next character that we would be traveling to. So, I overshot one more character to "W", then traveled to my "a" in "examp". If you think that exception sucks, you're right. It does. It's just another rule that can introduce human error into the equation.

Further, notice that I needed to wrap around the card, as we already expressed earlier. Yet, my border character technically came after "c" and before "Z". However, I still put the border character at the end. I am doing this for consistency with the rest of the password, so I don't have to keep yet another rule in my head.

Letting the OTG help

In this case, some sites do not allow non-alphanumeric characters in the password. In other words, it's letters and digits only. Part of the border pattern is that there is exactly one digit in the border for every row and every column. So, rather than overshooting to a non-alphanumeric character, you could just use the number in that row or column instead. This way, our previous password would be "Mt5bA1oQ7cZ7IA2".

Tack something onto the beginning or end

Of course, you could always just tack a special character or two at the beginning or end of the password. Your logic for how this is accomplished is up to you. You could use the beginning row/column border character in phase-2, or the ending row/column border character. Whatever makes the most sense for you.

Handling domains with non-alphabetic characters

Unfortunately, some domains have non-alphabetic characters in their domain name. Although seldom, they do exist, and OTG can't completely rule out the possibility that they will not be encountered. As such, in the center of the top border are 12 characters- the digits 0 through 9, the period and the dash. If these characters are encountered as part of traveling through the OTG with the domain, then travel to the character in the first row immediately below that character in the same column. For example, if your domain had a "5" in the domain, then you would travel to "f" in the first row in our example OTG card. If there are consecutive numbers in your domain, then unfortunately, I am not sure exactly how that is to be handled.

Criticisms, Thoughts and Conclusion

DOUBLE PHEW!!!

If you have made it to this point, you're determined to learn OTG. In my opinion, Steve's OTG paper system has some pretty serious problems:

  • The rules are technical and many, making the entire system very cumbersome to use.
  • Overall, creating your passwords are slow, slow, slow. Hopefully you store them in an encrypted database for retrieval, because recreating them is very slow, and not something you want to be fighting with when under stress.
  • Due to the cumbersome nature of OTG, creating your passwords can be very error prone.
  • The size of the OTG card is too large to fit into your wallet to carry with you, and see the characters on the grid without a magnifying glass.
  • If the card is lost, and the card is attributed to you, because you are using domains to create the passwords, the attacker could easily figure out the password to your accounts with the card. As such, you may want to prepend a 1- or 2-character salt onto the domain before beginning phase 1.

These are probably my biggest criticisms of the OTG system. While slick for a paper-based encryption system, it's a lot of visual scanning and lookups, a lot of rules and exceptions to remember, and a lot of areas that can create errors. Some die-hards may use this for their passwords, but I don't think I can recommend it, even to some of the most nerdy, security conscious friends I have.

In my opinion, the PasswordCard is a much more elegant system that doesn't require the user to keep a lot of rules and exceptions in their head, and if the card is lost, the attacker still has a great amount of work to do figuring out what the password is, and to which account it belongs to.

To be fair, the OTG system is marked as "Work in Progress", so there may be adjustments to the system in the future that make it more of an elegant system for creating passwords. But I think the whole thing will need to be reworked, as traversing a Latin Square to create passwords is just too cumbersome for practical use.

{ 4 } Comments

  1. Pierre | March 19, 2014 at 1:44 pm | Permalink

    why is your web site protected by impaired security levels RSA4096 (around 150 bit security) and SHA1 (80 bit security) which is being obsoleted by NIST ?

  2. Aaron Toponce | March 19, 2014 at 6:11 pm | Permalink

    Yeah, I've been meaning to address that. I have a good amount of readers that read my site from various browsers on different platforms, from different vendors, and different RSS readers. I've been meaning to research a lowest common denominator between everyone, without alienating anybody. So, for the time being, I've been doing the default cipher suite by using AES-256 in CBC, SHA1 MAC and 4096 RSA Diffie-Hellman. Thanks for bringing it up- I'll probably address it tonight, or this weekend.

  3. Aaron Toponce | March 19, 2014 at 6:20 pm | Permalink

    Digging into it, it appears that my certificate from RapidSSL only supports SHA1 for the message authentication. I wish I could support SHA256, but that would require purchasing a new certificate, which I may consider. While SHA1 is certainly broken, and I even blogged about that, which I reference in this series, I don't know that I'm going to lose any sleep about it right now, although looking forward, I'll definitely address it.

  4. Myra Shirey | January 28, 2016 at 12:03 am | Permalink

    Excellent! its Interesting and very helpful sharing.

Post a Comment

Your email is never published nor shared.