Imagine I'm signing up for the 99th new web site this month.
I somehow take my secret key (which I have written down on a card in my wallet) and the domain name of the site and feed them both into some algorithm (perhaps a HMAC?),
and type the resulting hash into the "password" field of the registration form.

Later, I'm at the library and I want to log in to that one particular site,
but I don't have my phone and the computers at the library are locked down so I can't install any new software,
so I want to reconstruct that password "by hand".

Is it reasonable to use Kerckhoffs's principle and assume that everyone knows exactly which hash algorithm I'm using, and assume every knows I use exactly the exactly the same hash algorithm and exactly the same secure key for web site all 99 web sites that I've signed up for this month?

It would be nice if somehow, even if the sysadmins for websites 1 through 98 all conspire together and share with each other the "password" I gave each one (and they know the algorithm I'm using), the hash is secure enough that finding the password for website 99 is harder than brute-forcing a random 8-character password.

It would be nice if somehow, even if all 99 sysadmins conspired together and shared the "password" I gave each one, the hash is secure enough the recovering my secret key is harder than brute-forcing a random 16-character password.

The amount of secret information I have to write down and put on a card in my wallet and keep secret should be shorter than simply making up a fresh new random 10 character password for each of 100 websites and adding the domain name and the new password to the card. (Perhaps 256 bits of information is reasonable? Perhaps encoded into 80 decimal digits or 55 lowercase letters or 20 Diceware words?).

You could trust yourself to keep your algorithm secret, so it could safely serve as your "key". But defending it against a couple of colluding web site admins would be harder. Do you consider that a realistic threat model? You could also modify it so you use a different algorithm for high value web site passwords, like banks.
–
John DetersNov 12 '13 at 21:51

+1 - I had a similar idea a few months ago, but my security restrictions were looser and I wanted to be able to do it in my head. I haven't really done much on it, though, aside from starting to learn to do hex XOR in my head.
–
ErhannisJul 10 '14 at 22:55

@JohnDeters: I agree that colluding web site admins is unrealistic. However, I have accounts on so many different websites that it is not unreasonable to suspect that at least 2 of those sites will accidentally leak my password to an attacker.
–
David CaryJul 29 '14 at 4:44

1 Answer
1

I don't think doing this by hand is the right way to do this. Pencil and paper systems are unreliable because humans just aren't as good at being robots as, well, robots! Most of the work in computing a secure MAC is hugely monotonous and a single mistake, anywhere during the process, could completely destroy any security you thought you had.

If your library computer has web access, then it executes Javascript with very high probability. Javascript is enough to conquer this problem.

Just create a static HTML with some Javascript in it. You have two HTML input fields with a single button. When you click, it computes the $HMAC(site,password)$ using SHA-256 or something, then encode the result as printable characters.

There is the problem of key loggers etc, grabbing your master password but they could just as easily covertly film you as you carry out the computation by hand!

There's a limit to the countermeasures that be deployed when the machine is fundamentally untrusted. However, you can mitigate against key loggers by simply making the master password be entered, character by character, via a dropdown box.