On Mon, Mar 30, 2009 at 9:46 AM, Mike McGrath <mmcgrath@xxxxxxxxxx> 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" _______________________________________________ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
