The Blums Mental Hash (BMH) algorithm, a programming exercise I worked on this last weekend, won't let me go. Quick review, the BMH is supposed to be a mental exercise you can go through to generate a unique password for any website. The algorithm and its intentions are explained here:
Good passwords are hard to remember. A pattern that makes a password memorable is likely to make it vulnerable to attack. If remembering one secure password is hard, remembering many such passwords is entirely impractical. So people who have gone to the effort of creating one good password use it for many different accounts. A security breach anywhere that password is used means that the password is vulnerable everywhere else it is used.
It is much safer to have different passwords for every account. Then if one password is compromised, the damage is limited to a single account. One way to accomplish this would be to have software compute a password for each account by encrypting the name of the account. For example, your password for Home Depot could be the result of encrypting the text "homedepot." This way accounts with different names would automatically have different passwords. (In practice, it might be possible but highly unlikely for two account names to result in the same password.)
Is it possible to create encryption algorithms that a human can execute but that a computer cannot break? It doesn't seem at first that this should be possible, but Turing Award winner Manuel Blum believes it may be. He presented his proposed algorithm at the Heidelberg Laureate Forum. He emphasized that his method takes a lot of up-front effort to learn but then it can be carried out quickly. To prove this claim, he demonstrated that at least one person has in fact used the method, namely himself! He said he can usually come up with a password in under 20 seconds.
There are a couple of questions that keep floating around in my head?
The problem of generating passwords on a per-site-basis is monumentally difficult. Yet, Blum's algorithm is pretty simple. It's still beyond what most (anyone?) would go through to generate a password, but it shows huge promise. It makes me wonder if the problem of generating passwords doesn't have some solution analogous to what the CAPTCHA provided against SPAM bots. In that case, most SPAM bots were stopped in their tracks all by using a technique that a PHP programmer could whip up in a couple hour's worth of work. (Hint: learn GD).
Another thought: the BMH works by walking through each letter in the domain name, and generating a unique password entry for it. At the core is a key which says how digits should be mapped to numbers, and from there, how they should be shuffled. I wonder if a physical device--think stack of cards, or string of beads--could be used to assist. Imagine if your key was a set of colored beads on a lanyard, and you used them to translate a domain name to a password. Crazy, but it almost seems possible.
And another: I always think of cryptography as requiring mind bending math skills. But the BMH shows that this doesn't need to be the case. You should study this algorithm, if only to appreciate that security doesn't need to come at the cost of complexity.
With the Bookmarklet in place, I can click my toolbar and be provided with a password that corresponds to the domain name in use. (Ssssh, don't tell anyone: my "password" for blogger.com is @TuZeMe@NiWaZe--Ni3).
There are a number of issues with the Bookmarklet, but the obvious (and fatal) one is that the keys are stored in the source code. That means that if you drag the Bookmarklet to your browser, you'll get the same passwords I do. Which is not what you intended. The solution would be to store the key parameters in the bookmarklet itself. But that would be messier than I need for this trivial example. Perhaps if I'm still infatuated with this algorithm next week, I'll add support for this.