[Beowulf] One time passwords and two factor authentication for a HPC setup (might be offtopic? )

[Rahul Nabar]

Thanks Bill; great comments. But they only make my decision harder. :)

On Mon, Oct 12, 2009 at 4:56 PM, Bill Broadley <bill at cse.ucdavis.edu> wrote:

> Seemed kinda silly to me.  My minimum level for security is something like ssh
> with certs.

Of course, we use ssh too. Are certs. the same as a public-key
private-key exchange?

>So various attacks don't work, things like spoofing dns, network
> sniffing, and man in the middle attacks don't work (assuming users with a clue).

What can "users with a clue" do to defeat these kinds of attacks? Yes,
users can choose smart passwords and protect them but how do users
factor into protecting against spoofing, network sniffing etc?

Of course, users are important for social engineering sort of attacks
but in these other more advanced hacking strategies how can users
protect themselves? I thought these were more ripe for sys admin level
security solutions.


>
> Sounds reasonable, so sure you get a one time password,
>the hard part is
> making sure nobody sees that password except the intended recipient.

Yes, agreed. But that problem exists whenever you use *any* password
exchange. OTP's just reduce the risk of an intercepted P/W being
continuously reused, correct?

>  So if
> you buy the yubikey then what?  Pam module?

I usually put my trust in PAM. Seems a large enough and Open Source
Project that in general ought to be vulnerability proof.

 > ssh client hack?

I wouldn't trust a ssh hack unless it was widely adopted and proven secure.

>Some webified
> openid setup?

Dones't sound too appealing. Webifying what can otherwise be done via
the command line is usally making things more insecure.

>I can't see any other way
> to let someone login from a smart phone (that lacks a powered usb port).

I was just shopping for a H/W token that generated OTPs It doesn't
have to actually connect to the login machine. The user could just
type in the OTP in response to a command line challenge.

> I'd agree there, but more secure than ssh with a valid known host (knowing the
> key of the server you are logging into) and a certificate... not so sure.

"Valid known hosts" are great but the reality is that many times users
travel and would like to log in from a Laptop or off-site login PC
that doesn't always have a static I/P etc.

> The one approach I've been considering is a smart phone with an out of band
> connection (wifi or cellular).  The server knows a public key associated with
> a user's smart phone.  The user's smartphone knows the public key associated
> with the server.  When you go to login a challenge is sent to your smart phone
> (encrypted in it's public key), a cute dialog pops on the cell phone asking
> the user if they accept the connection, and the response is sent to the server
> (encrypted in it's public key).

Great idea. But we'd have to impliment that from scratch, correct?
There is no app that does this for us automatically. I'd hate to write
a secure app. More than writing just about any app something that
needs to be secure requires a set of programming skills that I just
doubt we have in-house. Besides, unless it has a large base using and
trying to break it one would be unsure of its robustness.

> It would be single factor authentication (something you have), but much better
> than an average password which doesn't have much entropy and with which you
> have to trust the local client.  Well that's based on the idea that a smart
> phone is much less likely to get hacked then the average desktop.

Agreed.

-- 
Rahul