Feature request: FAIL_DELAY-support for sshd

[Christopher Rapier]

Hopefully people won't mind if I take up a contrary position. I'm not 
trying to step on any toes or insult anyone so please don't see this as 
a flame because it sure isn't meant as such.

I've been following this and I have to say that the solutions being 
proposed at this time are somewhat disconcerting to me. In a critical 
situation I might be harried, have my fingers off the home row, or jump 
the gun and start typing the password before the prompt appears. I 
really won't want to have to wait 5 to 10 seconds between each password 
attempt to try and get in. I've discussed this with some security people 
where I work (a research center) and they have similar concerns. More 
importantly, they aren't convinced that the security improvement will 
justify the additional costs/user problems/support issues.

Look at it this way - these people aren't really trying to brute force 
their way in as much as they are checking the doorknobs to see if some 
less than saavy admin has common usernames with common passwords (which 
means this option would have to be enabled by default to make a 
difference). For everyone else we get a few hundred connection attempts 
that don't lead anywhere and the attack moves on.

A sophisticated attacker will simply shift how they run their probes or 
accept the additional delay as part of the process (We've done work that 
shows low speed port scans and attacks that extend over several weeks in 
order to avoid triggering various IDS rules). Which means that the right 
thing to do would be to track who has been making connection attempts 
and automatically block them if it exceeds a certain value. Of course, 
that could cause significant problems for legitimate users if that value 
is set too low. So we set it to some value that assures that whoever is 
doing is an intruder - but how long are we supposed to sit on this 
connection data? By what mechanism will it be tracked? Will it be 
possible to exploit this mechanism itself for a DoS attack? All of which 
makes me think that this (at least) is outside of the bounds of what SSH 
is about.

Honestly, in my view the right thing to do to encourage admins to audit 
their user information to make sure common usernames like 'test' and 
'guest' either have strong passwords, only lead to restricted shells, 
or, optimally, are purged from the system.

I'm not saying this line of inquiry isn't worth discussing but I just 
don't think the solutions presented to date are the best answers to the 
problem.

Chris Rapier
pittsburgh supercomputing center