Re: OPIE considered insecure

Right, but that's not the problem they're trying to solve. They're trying to solve the problem of logging in _from_ an untrusted machine, to a trusted machine.

Okay, I got it backawrds.

So, an alternative might be to carry around a USB key with a one-time private key, different from your normal private keys, and have the public key command-squashed on the server to remove itself from authorized_keys before running the shell.

That's what I do -- multiple throw-away keys on a USB stick, for emergencies. However if you're that paranoid you better be carrying around your own set of ssh binaries on that stick as well.

You could generate several, each with a different passphrase (assuming that you could manage to remember that many passphrases and which keys they go with), and get a similar effect to printing out a card with the next ten OPIE passwords.

It's not that hard to come up with a scheme that lets you map from an identifier tagged to the private key to the corresponding password (in your head). It's a pain at the start, but once you've used a given scheme for a while it becomes second nature.

Akso, note that you can get similar behaviour using K5 with one-off instances of your principal (e.g. lyndon.a6d5mps@xxxxxxxxxxx). The advantage here is that there are no key files involved (but you still want to carry a trusted kinit binary with you). The downside is that most sites don't have K5/GSSAPI enabled. And of those that do, a significant percentage of the implementations still don't to dynamic realm discovery, therefore you need a pre-existing arrangement to map your realm to the appropriate KDCs.


Happiness is a good martini, a good meal, a good cigar, and a good woman ...
or a bad woman, depending on how much happiness you can stand.
-- George Burns
freebsd-security@xxxxxxxxxxx mailing list
To unsubscribe, send any mail to "freebsd-security-unsubscribe@xxxxxxxxxxx"