NOW SpinRite 6.1 – Fast and useful for spinning and solid state mass storage!

Off The Grid
Security Features, Goals & Design
AN UNFORTUNATE TRUTH:  The ongoing problem is website security breaches conclusively demonstrates that sites which require us to login and authenticate our identities cannot be trusted to keep our passwords secret. This makes password reuse at multiple sites extremely unsafe. If one site leaks our name, eMail address, and password to a hacker they attempt to reuse that authentication to impersonate us on other sites.
Or, as the infamous Lulz Security hacking group, “LulzSec”, tweeted at
10:34am, Friday, June 24th, 2011 . . . phrasing it somewhat less delicately:
@LulzSec: Reusing passwords is kind of like owning
multiple houses and using the same key for each one.
Don't expect people not to steal your shit.
Fri 24 Jun 10:34 via web (received via TweetDeck)
Until an industry-wide, coherent identity authentication solution is
established, the responsibility for creating a potentially limitless
number of separate website “identities” rests with each individual.

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.

We have seen over and over that anything which
relies upon technology can be compromised.

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.

For these reasons, among others, many users
refuse to centralize their password management.

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.

What would such a system look like?
What would its requirements be?

Here were my requirements:

See the next page “How to use the OTG system
for an understanding of how the system works.
Off The Grid Resource Pages:

Jump to top of page
Gibson Research Corporation is owned and operated by Steve Gibson.  The contents
of this page are Copyright (c) 2024 Gibson Research Corporation. SpinRite, ShieldsUP,
NanoProbe, and any other indicated trademarks are registered trademarks of Gibson
Research Corporation, Laguna Hills, CA, USA. GRC's web and customer privacy policy.
Jump to top of page

Last Edit: Aug 16, 2011 at 11:30 (4,694.19 days ago)Viewed 2 times per day