[ILUG] SSH dictionary attacks.

[Aine Douglas]

On 8/25/06, Colm MacCarthaigh <colm at stdlib.net> wrote:
> On Fri, Aug 25, 2006 at 06:25:11PM +0100, Aine Douglas wrote:
> > On 8/25/06, Badger <badger at scattermail.com> wrote:
> > >I agree with what Colm Mac Carthaigh said in the alternate reply
> > >to your post Aine, but I just wanted to drill down on some of the
> > >other points:
> >
> > What Colm said was that anyone could implement their own tool using
> > the PKCS standards, break the standard and make it do something
> > entirely different.
>
> No, thats not quite what I'm saying, You're missing the broader, more
> profound, point. The security you are talking about with the ROS is
> merely that you're only allowed use one tool which has its own password
> policy enforcement. There is no inherent PKI or crypto magic going
> on which actually enforces this.

Well, actually you probably need to enroll in Ros to see that there
is. If you change the password, then when you come to use your digital
credentials, you won't be able to, unless of course you run your newly
set password back through the encoding routines used in the ros applet
and have a new highlevel input to put in.

> The real point is that this wouldn't work with ssh, and the notion that
> it possibly could can only be founded in ignorance. There are already
> widely deployed SSH clients which will allow to use PEM, DSA, RSA, BLOB,
> an agent daemon, and a range of other keystores.

Ok, and my point is, that in a real world scenario where maybe like
some large managed services firm, I have 50 engineers accessing
servers by SSH, and I need to enforce control over that, I need a way
to centrally control what keys can access what servers, and have the
ability to centrally revoke certs. I can only really centrally revoke
certs that I issued. I would do this through CA generated CRL's, or
certificate revocation lists. The cryptographic standards exist for
server components which maintain trusted key stores, as SSHD does, to
automatically check for CRLS, and cease operating if it doesn't find
them.

There would actually be a policy that a CRL must be produced at a
specific time interval, a day, week, month, year, etc, and that could
even be an empty list, but it must be published.

> Even if it an SSH client were implemented which enforced the password
> HMAC scheme for PKCS12, there would be no beenfit, because one of the
> other keystores could be used anyway. That's not implementing their
> own tool, or "hacking", or it's using the default behaviour of the tool.

In a centrally controlled environment, I would demand that I was in a
position to centrally disable all other keystore types to conform to
my policy. I wouldn't want a situation to exist where any private key
hit a disk, unprotected ram, or pagefile.

> Another problem is that as SSH is a widely deployed standardised
> protocol it wouldn't take very long before a version of the client was
> available which ommitted this annoyance of a "feature" for users. Users
> like being able to encrypt their keys with arbitrary passwords.

Yeah sure, I get that, and I agree with that. But in the context of
being an admin in a controlled environement, I want to define the
policies of what goes on and what doesn't go on, and if I could
enforce such rules I'd do so within my organisation. I'd have no
problem letting users encrypt their keys with arbitrary passwords so
long as the keys had a very short validity period :-)

> > I could re-write a webserver and make it a mailserver.
>
> I've done both, Apache httpd and bits of mod_smtpd. Guess I'm a hacker
> ;-)

heh...

> > could rewrite a telnet tool and make it talk SSH.
>
> Hmmm, helped do that too, I think I'm still in the credits file for
> PuTTy.

Would you like to be in the credits for the enterprise version?  ;-)

> > You could turn a road into a canal if you build walls and add tanking.
>
> Now *that* sounds like a challenge, and I am moving to the Netherlands
> on Monday.

Why move to the Netherlands.... there's a port tunnel canal project in
Dublin that could use your talent!

Aine.