WHAT WE NEED:
We need to somehow arrange to use a different, strong, secure and complex password for each site that requires us to invent an identity so that we can reauthenticate our identity upon our subsequent return.

Security conscious users know that passwords need to be complex and long to be safe. And GRC's Password Haystacks password padding approach offers one solution in this battle to construct secure and memorable passwords. But the trouble is, we need to create a potentially unlimited number of unique passwords. It's one thing to create and memorize and/or record a strong and unique password where we have to, for our most important sites, such as banking and eCommerce. But today we're asked to create passwords even for “throwaway” sites we visit once and may never return to, just to post some feedback in a forum or blog. And if we do return, what was that password we created the last time?

The problem has been so intractable and pervasive that many “high-tech” and highly useful solutions, such as LastPass, KeePass, and SuperGenPass have been created to lift some of the password management burden from overwhelmed users. But all of these solutions also have liabilities. In mid 2011, LastPass users had a scare when it was revealed that some of its users' database may have escaped LastPass' control. It's convenient to have all of our authentication information stored “in the cloud” . . . but only so long as it is never stolen. And it has been demonstrated that SuperGenPass users may be exposing their critical master password to malicious websites.

The other concern with cloud-based storage is availability. It's convenient . . . as long as the service is available. Also in mid 2011, the United States FBI (Federal Bureau of Investigation) confiscated three “racks” worth of web servers, reportedly because they could not be bothered to determine which single server among them was believed to be violating the law. In the process, several score of unrelated web sites disappeared from the Internet. We would not be happy if the cloud-based password manager we depend upon was among them.

Faced with these many, and growing, problems . . . a new solution was needed.

Immediately after finishing the work on the Password Haystacks password padding approach, I wanted to look in a different direction. My idea was to see whether I could design a secure cryptographic “paper cipher” requiring, for its use, no instrumentality, no technology, no computers, no software, no wires — only a simple piece of paper of some kind. A computer would certainly be required to design and print any instance of the Cipher. But once that was done, no computer would be required to use it.

This is the core of the idea I started with:

The idea of using a computer to encrypt a domain name to create a per-domain password is not new. That's the idea underlying SuperGenPass and others. Its obvious benefit is that instead of needing to record, store, or memorize random passwords that we invent per domain — with the potential problems that invites — we employ an algorithm of some sort to create — and recreate in the future — domain-name-based passwords. Then we don't need to record, store, or memorize them because we can simply recreate the same password from the same domain name any time it's needed. It's a great idea with no obvious drawbacks . . . except that all available solutions are “online” (in one sense or another) and suffer from the potential of worrisome privacy and security breach problems.

Here were my requirements:

• Easy to use
  I wasn't doing this as an intellectual curiosity. My absolute goal was to create a solution that anyone interested in creating secure passwords could learn to use quickly, and would then find to be useful and even fun to use.
• Secure
  The system's security was, of course, as crucial as ease of use. This new system needed to be at least as secure as anything and everything it was replacing so that users could be confident that they were generating passwords that could not be “reverse engineered” to learn anything that might render the system less than absolutely secure. And by assisting its users to create much more secure passwords than they were normally likely to, it would be proactively increasing their security.

  What  EXACTLY  do we mean by “high security”?

  	The encrypted password output must be long enough to thwart brute force attacks. The Off The Grid (OTG) expands every case-insensitive input character (a-z) into a pair of unpredictable characters. The first six (input) characters of a domain name are therefore expanded into 12 output characters: A very short domain name such as “grc” can be enciphered as “grc.co”, using the joining dot (.) and some of the top level domain name to obtain six input characters. And, as we'll see, even shorter domain names can also be expanded into 12 enciphered characters.
  	The enciphered output depends upon ALL input characters. This is an important property for high security. A minimal change to the input must result in a maximum and unpredictable change in the enciphered output. In the two examples below – which were generated by the OTG system – only the first and the last character was changed in the domain name “amazon”:
  	Every user's enciphered output is completely different from that of every other. When any user enciphers a domain name — even the same domain name — using their own OTG cipher, they will obtain a completely unique result, different from any other user:
  	Disclosure of SOME domain names and enciphered passwords must NOT compromise the security of ANY other passwords. Even if an attacker knew that you were generating your passwords with the OTG system — and that is not obvious from its output — and if an attacker were to somehow acquire some of your passwords generated by the OTG system, it is imperative that so little about your OTG cipher could be determined that none of your other passwords would be weakened. As we will see, the OTG system achieves this by embedding an extremely large amount of “entropy” (randomly determined data) into each instance of a user's personal, custom cipher grid.
  	Resistance to “computational” attack. Today's computer hobbyists (and attackers) have access to phenomenal computing power thanks to the awesome power built into modern PC graphics processing units (GPUs). OTG resists computational attacks by drawing upon a large “pool of entropy” that is unknown to attackers. Its design significantly obscures each cipher grid instance's configuration details even when the operation of the OTG system itself is known.
  	Everything about the OTG system can be fully disclosed. The design of the OTG system compliant with Kerckhoff's Principle, which states that: “The security of a cryptosystem must not be dependent upon the nondisclosure of the algorithm; it should only depend upon the nondisclosure of the key.” Everything about the design and operation of OTG is disclosed here. Nothing is kept secret and nothing needs to be. Yet attackers gain nothing that might help them to crack any user's password sets.

• Compatible
  If the Cipher produced a password that a website could not accept we'd be in trouble. If we were simply making up a password, we would adapt what we've made up to the website's rules and restrictions and store the result. But the OTG system's goal is to free us of having to remember anything. We solve this by using the system's Grid to generate a secure lowest-common-denominator password, and additionally provide a means for optionally adding special characters for those websites which allow them. By restricting the system's output (unlike the somewhat extreme examples above) to upper and lowercase alphabetic characters, we obtain maximum compatibility with all websites — with sufficient security provided by the password's length. (At one hundred billion attempts per second, 127 years to crack.) While that doesn't provide as much security as including special characters, this provides compatibility with the great number of sites that still do not allow the use of any special characters. And adding special characters is also explicitly and fully supported by the OTG system. (And note that any other password generator would face the same limitations while providing a less user-friendly solution.)
• Variable security
  Today's websites have differing rules for password length. For reasons of their own, some sites place lower and/or upper limits on the lengths of the passwords they will accept. So any robust password ciphering system should be able to generate domain-name-based password strings of any length. The OTG system can.
• Flexible & powerful
  A flexible password generating system should be able, when needed, to generate “alternate” passwords for a given domain name. This might be useful if the primary password is compromised, or if a site's password policies requires its passwords to be changed periodically. A system that cannot generate alternate passwords on demand would prove too limited. OTG readily produces up to 52 unique and completely different passwords for every domain name.
• Everlasting & future proof
  Technology moves at a rapid pace, often obsoleting older technologies. How many people are still able to play 33 RPM vinyl record albums or 8-track tapes with the equipment they have in their homes or in their cars? Sometimes a solution that does not depend upon technology is superior because you'll never find yourself unable to “play” it. Because it is just a carefully constructed piece of paper, the OTG system can be used fifty years from now if we're stuck using passwords until then.
• Utterly reliable
  The OTG system requires no instrumentality, uses no power, no batteries, no computers. It cannot be rendered obsolete by some future upgrade. You won't be without it if a web browser upgrade no longer supports its earlier plug-ins (as does often happen), or if the company providing a free service starts charging for it, is acquired by another company, or goes out of business. It's yours forever. There's nothing to break.
• Universal
  Since OTG can encipher ANY textual input into a deterministic string of encrypted output, which can be readily recreated at any future time, it can be used for any other purposes as well. For example, if a file must be encrypted with a secret key known only to the sender and one or more receivers, all parties could have an identical instance of a single OTG grid used just for this purpose. The sender encrypts a (plaintext) string of six to eight characters, which is then used as the key to encrypt the file. The user sends the file along with the plaintext string in the clear without any concern about eavesdroppers. Only the recipient with the same instance of the OTG grid can take the plaintext string and encipher it into the same key to decrypt the file.