Re: Darn skiddies (ssh login attempts)
On Mon, Apr 04, 2005 at 09:46:26AM -0700, Chris Adams wrote:
Policy was the wrong word - the basic idea is just that either way the
users have a password but a private key isn't directly replayable since
the attacker doesn't actually receive the key information or password.
Depending on the attack. That's the point I'm making--rsa keys protect
against certain attacks but do absolutely nothing about other attacks
and shouldn't be seen as a magic bullet.
Central distribution is also quite easy and allows you to decide how
much control you want over the process - simply change the authorized
key path to a directory which isn't user-writable and use your existing
management tools to synchronize changed keys.
Dude, that does *nothing* to manage the private key.
Not entirely. With passwords there's the important requirement that a
password actually be sent through a compromised machine. With private
keys, you're in trouble if any machine that the user happened to leave
the key on gets compromised.
Only if the key wasn't protected with a password - sure, it's possible
for an attacker to brute-force the key but that's a lot more work than
they'd have to do if you're using password authentication and it gives
you more time to detect the intrusion and get users to change their keys.
Huh? You do realize that the passphrase on the private key can be brute
forced, and that it's possible to do so without connecting to the target
system at all? (So that there is no record that someone is trying to
brute-force the key password.)
More importantly, good policy also tells users to use ssh-agent instead
of copying private keys all over the place - sure, not everyone will do
it but the same is true of password policies
No, password policies are enforceable--you control what the user can set
the password to. Key management policies are not enforceable. ssh-agent
also intruduces another vulnerability in that new sessions can be
started using the secret key for authentication without the user being
aware that it's happening.
The easiest way is simply to replace ssh-keygen with a wrapper which
calls cracklib before passing the password to the real ssh-keygen. This
also has the advantage of reusing any existing cracklib policy.
Interesting. Now how do you keep the user from resetting their password
on any system where you aren't controlling the ssh-keygen?
Mike Stone
Reply to: