[Beowulf] One time password generators...

[Robert G. Brown]

On Wed, 25 Mar 2009, stephen mulcahy wrote:

> Billy Crook wrote:
>> If you want to spend as little as possible:
>> http://www.cl.cam.ac.uk/~mgk25/otpw.html
>
> This looks pretty good on paper and as a bonus (for us Debian users at least 
> ;) it's included in Debian Lenny and up.

On paper is right!  It requires one to carry around paper or a PDA of
some sort to literally look up a OTP.

> I wonder has anyone done an analysis of the security of this?

One problem is that I'm not sure that this meets the requirements for
two-factor security according to the due-diligence spec of e.g. a bank.

I fail to see how it is more secure than e.g. dumping /dev/random
through an ascii translator and into a file, and just working through
the file sequentially on both ends -- in fact, to me it seems to be less
secure, because it is at least partially keyed and there seems to be no
point in having a key if you're going to carry a table of shared secrets
around with you.  One way or the other, one has to carry the PSK file
with you -- printed on paper, on a USB stick.  Paper has the obvious
problem that you can run out of passwords.  A USB stick could hold
enough to not run out, but is subject to snooping on the host you're
using to read it while logging in.  All of them are subject to the
theft/loss of the USB stick or paper, all of them are subject to man in
the middle on the host you're logging in from.  Basically, if you are
logging in from an untrusted host you can ALWAYS be presented with a
SHELL that records your login keystrokes, logs in as you, permits you to
do your work by passing through both directions of the traffic
transparently, and then simply simulates your logout on your end while
holding on to the remote shell.

To me this suggests that the real marginal benefit of ALL of the
two-factor authentication methods, secureid or otpw or whatever, is that
it raises the bar a tiny bit on a snooper presumed to have root control
of a system one is coming in from.  Really, just a tiny bit.  I don't
think that it would be terribly difficult to write a general purpose
network module for any operating system that could both sit in the
middle and offer up a trojan port for a third party to come in at will
and take over the "terminated" session(s) from an arbitrary
remote/breakout site.  The attacker might not have the convenience of
being able to login as you whenever they want, as the session in
question cannot be restarted once THEY choose to terminate it, but hey,
do they NEED to be able to restart it or can they do tremendous damage
at the end of the one session?  I rather think the latter.

Yeah, raising the bar even this trifle probably knocks out most of the
simple script-kiddies and over the counter rootkit or web-borne viral
spyware on Windoze boxen, but they aren't the real problem with
high-profile targets such as banks or organizations with lots of e.g.
SSNs and personal data.  The danger there is the professional
ubercracker, the very person two-factor auth is supposed to foil.  OTP
in general doesn't really foil them.  The ONLY thing that can foil them,
really, is to have trusted/trustable systems on both ends of a
connection, in which case plain old one factor passwordless shared
secret ssh is more than adequate -- if you brought your own secrets.

Try explaining that to a security officer at a bank, of course, and
you'll get a polite smile and a CYA insistence that you use two-factor
auth anyway or you aren't getting close to their data.  And besides,
what can they do?  The majority of the clients accessing protected
servers in the internet Universe is still Windows, and Windows security
is a really, really unfunny joke.

IMO a secure login from a Windows box is an oxymoron, no matter what the
authentication factors used or software interface in question might be,
but alas, I haven't yet seen questions on a due-diligence form that
mandates the non-use of Windows systems as clients permitted to access
the protected data/server.

The fundamental problem with security is that it is a weak-link problem.
You are never more secure than the weakest exploitable chink in your
armor.  You can pile on locks and armed guards at the door to let in
only properly authenticated sheep, but that will never prevent the
egress of a properly disguised wolf, or a wolf that goes in through the
wide open window on the side of the barn.  You therefore have to extend
the security perimeter to the meadow where the sheep play no matter what
or you are just fooling yourself.

And I say this as a sheep.  I work on lots of very secure systems with
confidential data on them and with root privileges.  I don't sweat the
integrity of the ssh sessions themselves -- if ssh is cracked
civilization as we know it is doomed anyway, no due diligence can
protect you then.  I sweat over the crackability of my laptop.  It has
to be just as secure as the systems I log into, and yeah, I can't afford
to have it get stolen as my ssh keys are right there on its disk,
readable by anyone who reaches root, just as my passwords are snoopable
by anyone who reaches root, just as the connections themselves can
easily be hijacked by anyone who reaches root.

Running nightly-yum-updated linux with basically no open ports, I can
sleep at night.  I >>would<< sleep better with a two-factor auth system
in place -- every little bit helps.  But nothing, really, provides
protection against the pro-grade ubercracker, one who can take over your
system at the kernel level, once they gain access as root or as myself
(who pops in and out of being root all day).

Well, that's not quite true.  Monitoring and reading the logs on the
servers, on the firewalls, paying attention, using passive no-open-port
network monitors on the switched wires, looking for anomalies -- that,
and the fact that relatively stupid script-kiddie crackers often have
broken scripts that leave footprints where ubercracker tools in the
hands of an ubercracker do not -- give sysadmins a fighting chance.  But
no more than that.  One has to BE an ubercracker (just a white-hat one)
to defend effectively against an ubercracker.

    rgb

>
> -stephen
>
> -- 
> Stephen Mulcahy     Atlantic Linux         http://www.atlanticlinux.ie
> Registered in Ireland, no. 376591 (144 Ros Caoin, Roscam, Galway)
>

Robert G. Brown	                       http://www.phy.duke.edu/~rgb/
Duke University Dept. of Physics, Box 90305
Durham, N.C. 27708-0305
Phone: 1-919-660-2567  Fax: 919-660-2525     email:rgb at phy.duke.edu