OPIE considered insecure
Lyndon Nerenberg
lyndon at orthanc.ca
Mon Feb 9 14:13:42 PST 2009
> 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 at EXAMPLE.ORG). 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.
--lyndon
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
More information about the freebsd-security
mailing list