Intrusion Update

[Stephen John Smoogen]

On Mon, Mar 30, 2009 at 9:46 AM, Mike McGrath <mmcgrath at 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.


-- 
Stephen J Smoogen. -- BSD/GNU/Linux
How far that little candle throws his beams! So shines a good deed
in a naughty world. = Shakespeare. "The Merchant of Venice"