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.
@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)
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:
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:
|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.|
Gibson Research Corporation is owned and operated by Steve Gibson. The contents
of this page are Copyright (c) 2016 Gibson Research Corporation. SpinRite, ShieldsUP,
NanoProbe, and any other indicated trademarks are registered trademarks of Gibson
|Last Edit: Aug 16, 2011 at 11:30 (2,047.79 days ago)||Viewed 3 times per day|