[ILUG] SSH dictionary attacks.

[Colm MacCarthaigh]

On Fri, Aug 25, 2006 at 09:17:21PM +0100, Aine Douglas wrote:
> 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.

I don't need to register :-) One of the two following 3 scenarios
is what is being done;

	a) the password encrypts the key. Supplying the password
	   decrypts the key locally, and it's then used as normal.

	b) the key and a password are both required authentication
	   tokens. Similar to requiring both an ssh key and keyboard
	   interactive authentication. 

	c) the protocol issues a challenge which requires a three-input 
	   algorithim, the inputs being the challenge, the key and the
	   password. The challenge might even say "run the password
	   algorithim 10 times, but the key algorithim 12 times", which
	   absolutely requires to you keep them seperate. But still,
	   you can just consider the password to be a small key.

But the problem with all of those is that the arbitrary key/text that is
the password can always be re-encrypted or its storage mechanism
changed.  There really is no cryptographic control at this. There just
is absolutely no mechanism by which a server can divine the strength of
security surrounding the client key storage, all it ever gets to see
is numbers. 

Paul's original point stands, you do genuinely lose the absility to
enforce password strength, although in scenario (b) we just implement
Paul's suggestion anyway. 

The ROS system is just convoluted trickery for a single application, it
doesn't solve the problem generally.  Because unfortunately there is no
general solution.
	
> 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 thought we needed a method to enforce password strength :-)

> 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.

You could do that at a top-level policy level; e.g. you could fire
people for doing it, but there isn't really a technological means of
doing it. 

> >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 :-)

*shrug*, I'd just use a one time password system for all of this,
much much easier and cheaper all round. But that's me ;-)

-- 
Colm MacCárthaigh                        Public Key: colm+pgp at stdlib.net