Re: Darn skiddies (ssh login attempts)
On Mon, Apr 04, 2005 at 10:50:48AM -0700, Chris Adams wrote:
They were also never portrayed as such - merely an additional layer of
protection
It's not an additional layer if you replace passwords with keys.
It allows you to step in the middle of the process - it's not simply a
question of dropping a file in ~/.ssh/ with no checks. Since the user
can't use any key they want this allows you have, say, a process of
requiring a decent password, stashing the public key somewhere else,
making the private key file immutable to prevent password changes or
removal, and record an audit log entry (all of which could be done by an
ssh-keygen wrapper).
Which implies that you're controlling both the client and the server,
which begs the question of why you're exposed to attacks from random
hosts in the first place...
All of which is irrelevent - we're comparing it to plaintext
authentication, where our hypothetical attacker already has their
password without having to brute force anything. It also requires you to
have a copy of the keyfile in the first place, which is harder than
firing up an ssh brute-force bot.
So you're comparing a MITM password attack to a secret key brute force
attack. Apples and oranges, anyone?
Right, but in the real world password policies don't work so well
because normal humans don't handle high-entropy passwords well and
they're going to find an algorithm which your policy doesn't catch,
So? If you can't figure out the algorithm with brute force attacks
(e.g., cracklib) it's fairly likely that an attacker using the same
techniques can't either--which means that the password policy takes care
of the attack we started out talking about at the start of the thread.
These worms aren't using secret password cracking mojo, they're largely
trying things like account guest/password guest and other trivially
preventable problems. The compromises I've seen due to these ssh worms
that are going around have *all* been on systems that didn't enforce
strong password policies. That's why I find it vaguely humorous when
people suggest that replacing the passwords with ssh keys is the right
solution and then wave their hands about the key management problem. The
tools and (admin/user) education needed to enforce password practices
are *trivial* to implement compared to the tools and education required
to secure private keys properly. If someone didn't implement passwords
well, suggesting that switching to ssh keys without doing else will
solve their security problems is a bit, well, far-fetched. ssh keys
*can* be an effective tools, but *only* after doing a good risk
assessment, understanding and accepting the new risks that ssh keys
bring, and coming up with a good plan for deploying and using them in a
secure manner.
generate helpdesk traffic due to lost passwords
As opposed to forgotten key passwords? Seems like a wash to me.
and store it insecurely because they don't always remember it.
Insecure storage is at the heart of the problems with ssh keys--you
can't (with any sort of credibility) argue that users *can* store keys
securely but *can't* store passwords securely.
That's not actually true for all ssh-agent implementations
And how do you control the client-side agent? The protocol allows it, so
it's a vulnerability.
case, it's simply restating a point which was never in question: if the
Sure it was. At one point you (or someone) said that ssh keys were great
because they couldn't be captured at intermediate hosts. But if you're
forwarding the agent that attack vector is a wash.
The system I outlined above means that they can't simply use any random
ssh key but, frankly, if your users are actively trying to subvert your
security system you have bigger problems than script kiddies.
Welcome to real life. If your security relies entirely on users doing
the right thing all the time you're going to get burned. A good security
policy requires informed users but also some mechanisms to make it
harder for people to screw up--unless your userbase is entirely
infallible. (And I, for one, will welcome our new robotic overlords. :-)
Mike Stone
Reply to: