[Beowulf] One time password generators...

[Robert G. Brown]

On Wed, 25 Mar 2009, Lux, James P wrote:

> For SecureID, you can set up your application to periodically reauthenticate
> either on a clock schedule or when you ask to do things that are
> particularly sensitive (>ftp GET “nuclear weapon release code”... Please
> reauthenticate..).   Since knowing the pseudorandom 6 digit number now
> doesn’t help you some 60 seconds into the future, you can make this pretty
> strong (at the cost of annoyance).

A trivial annoyance to the ubercracker.  Remember, his agent is
intercepting ALL of your passwords and passing them through, and
snooping ALL of the data returned.  You might prevent him from looking
up the code himself later in the session. You won't prevent him from
seeing what you see, ever, or holding onto the session itself (which
will often give him the opportunity to trojan the server itself and
completely bypass its usual auth scheme, subject to firewalls and
monitoring in between).

> For FIPS201 badges, since they have both contact and contactless interfaces,
> you can do a strategy where the initial authentication is via the contact
> interface (which can see the crypto engine), and then you periodically ping
> the RFID part to make sure that the physical badge is still in the vicinity.
> (or, more painfully, make it so that the badge has to be always connected..
> But that raises real usability issues with having two computers)
> 
> As always, the idea is to require both “a thing you know” and a “a thing you
> have”.. The man in the middle can figure out the thing you know (e.g. By a
> spoof interface that grabs keystrokes), but it’s tough to emulate the “thing
> you have”, since it’s behavior over time isn’t predictable.

There's man in the middle as in out on the Internet, and there's man in
the middle as in "owning your client".  I claim that the former is
trivially solved already by ordinary ssh, the latter cannot be solved,
period.  Access of any sort from a compromised client compromises the
protected host, quite possibly seriously compromises it.

Although yeah, adding multiple auths adds both annoyance and an
incrementally raising bar...

Booting your access host from a read-only flash drive, with built in PSK
credentials -- now THAT'S two-factor authentication.

>       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.
> 
> I would qualify the Windows Box term.. If you lockdown the software
> configuration, I think one can make sure it’s relatively secure.  If you

Sure.  But that's simply controlling the incoming client, and I AGREE
that this is what one has to do to make ANYTHING secure.  Now
demonstrate to me any additional advantage to using yubikeys, secureids,
or anything else you like over simple ssl or ssh bidirectionally secured
unspoofable unsnoopable connections with no password at all.

Passwords are overrated.  In fact, they are very nearly pointless as far
as strong security is concerned -- they add almost nothing once you've
established two reliable endpoints with an encrypted link between them,
provided only that the mechanism for establishing the link cannot itself
be snooped or cracked.  And there are at least three (related) ways to
do that that I know of, probably more.

> allow casual admin access to install whatever apps you want, then, yes, it’s
> insecure.  However, most banks (for example) do NOT do this, at least for
> inhouse PCs.. They rigorously control the software image (to the extent that
> you boot from a shared image over the network).. The only thing on the local
> disk is essentially a “cache” which gets compared/refreshed against the
> master image.  No sticking in random USB widgets either.. If it looks like a
> disk drive, it gets encrypted (causing wailing and gnashing of teeth for
> employees who plug their MP3 players or cameras in).

All pointless, presuming a compromised system anywhere, all overkill
assuming a secure system on both ends.  Well, not quite overkill -- part
of this is MAKING the system secure, which I strongly approve of.  And
there is a point to encrypting drives, because drives can be stolen by
non-ubercrackers.  No ubercracker would deign to steal a drive, because
the way he gets access is on the backs of those with perfect rights and
permissions granting access.  He can't get those after the fact, from an
encrypted stolen drive.

> And yes, they DO have a variety of processes in place to require business
> partners to have appropriately secured systems.

Not an easy problem -- I'm not making fun of it, and a lot of what they
require, while inadequate and somewhat misleading, is indeed helpful
against certain things.  Close the doors you can, then cross your
fingers.

> Where it gets loose is the “customer contact at home” end, where they’re
> trading off annoyance of customers against security.  This is like the
> credit card fraud situation.. If you lock it down, nobody will be able to
> use the card, so you trade off some losses (a few percent) against having
> volume.

Security is always a cost-benefit problem.  More secure is more
annoying and harder and more expensive to use.  Easy to use for idiots
is almost always equivalent to insecure, although Linux does far, far
better for those idiots that Windows does -- consumer Windows goes out
of its way to be vulnerable, which is what is so annoying about it.
Default insecure, not default secure.  And their silly tell-me-twices
don't make them a damn iota more secure...

    rgb

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