So I'm not quite sure how to 'fix' this problem.  By that I mean, even if we knew this attack was going to happen I'm not totally sure of a feasible solution, using only free software, that we could have used to fix it. Obviously a physical rsa key or the like would have worked but I don't think we have the manpower nor budget to implement such a system.  So I ask the list, any ideas?

A single use random code/passwd mailed/texted each time one tries to login and invalidated just after use??

Basically I am referring to RFC 2289[1]

[1]http://www.ietf.org/rfc/rfc2289.txt

Thanks.

On Mon, 30 Mar 2009, Damian Myerscough wrote:

Hello,

What about the use of S/Key (one-time passwords) I think it is possible to deploy SSH with S/Key authentication. I haven't look into it that much but it could be a possible solution?

If someone had my username, password, and ssh key. How would that prevent them from getting a otp?

-Mike

susmit shannigrahi wrote:

...

...

So I'm not quite sure how to 'fix' this problem. By that I mean, even if we knew this attack was going to happen I'm not totally sure of a feasible solution, using only free software, that we could have used to fix it. Obviously a physical rsa key or the like would have worked but I don't think we have the manpower nor budget to implement such a system. So I ask the list, any ideas?

A single use random code/passwd mailed/texted each time one tries to login and invalidated just after use??

Basically I am referring to RFC 2289[1]

[1]http://www.ietf.org/rfc/rfc2289.txt

Thanks.

-- Regards, Damian Myerscough

---

Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list

Date: Mon, 30 Mar 2009 16:52:24 +0100 From: Damian Myerscough damian.myerscough@gmail.com To: Mike McGrath mmcgrath@redhat.com Cc: Fedora Infrastructure fedora-infrastructure-list@redhat.com Subject: Re: Intrusion Update

I have just done some research on SSH and S/Key and I read that S/Key cannot withstand a brute forced attack [1]

[1] http://www.gentoo-wiki.info/OpenSSH_skey

In addition, skey-like authentication schemes only work if the end users of aren't automating their login process and keep the skey-like program on a separate system like a pda.

Believe me, if you implement an skey-alike you will have users dumb enough to automate their login processes and run the skey-like calculator on the same machine they are logging in from.

Damian Myerscough wrote:

I have just done some research on SSH and S/Key and I read that S/Key cannot withstand a brute forced attack [1]

[1] http://www.gentoo-wiki.info/OpenSSH_skey

OTPW looks better:

http://en.wikipedia.org/wiki/OTPW

On Mon, 30 Mar 2009, susmit shannigrahi wrote:

...

If someone had my username, password, and ssh key.  How would that prevent them from getting a otp?

Supposedly, they will not have access to the mobile device/pager where this single time password will be sent.

Interestingly I saw someone doing something very similar to this at pycon using asterisk.

-Mike

On Mon, 30 Mar 2009, susmit shannigrahi wrote:

...

...

Supposedly, they will not have access to the mobile device/pager where this single time password will be sent.

Interestingly I saw someone doing something very similar to this at pycon using asterisk.

You mean, pretend to be another number using asterix and grab this single time passwd?

I mean calling people when they try to log in.

-Mike

On Mon, Mar 30, 2009 at 9:46 AM, Mike McGrath mmcgrath@redhat.com wrote:

On Mon, 30 Mar 2009, Damian Myerscough wrote:

...

Hello,

What about the use of S/Key (one-time passwords) I think it is possible to deploy SSH with S/Key authentication. I haven't look into it that much but it could be a possible solution?

If someone had my username, password, and ssh key.  How would that prevent them from getting a otp?

-Mike

Well normally they would have only your 1st password... and you would need a new OTP to become root etc. The big problem with S/KEY is the short search space (8 ASCII characters basically which can still take Petabytes for a dictionary attack).

A place I used to work at had a similar problem a couple of years ago. Lessons learned was that OTP passwords were one of the most effective limiters. The second limiter was time limits on kerberos keys which limited how long having an OTP was useful to the attacker. Where people had gotten around this, we ran into issues:

1) Kerberos tickets with long lifes. 2) Forwarding tickets with high trust between all systems. 3) Proxiable tickets working between clusters 4) sudo without password

Where people run into problems are:

1) Writing down the OTP passwords in their computer 2) Running the OTP calculator on their computer versus seperate device. 3) OTP passwords with 2 short of a length (8 minimum)

Also in the end some processes MUST have human interaction. Depending on the level of trust you wish to impart on something, packages may only be signed on certain machines, from certain terminals, booted from cold boot via secure media, etc etc.