bugtraq - Re: Strengthen OpenSSH security?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4446FE35.9040109@e2open.com>
Date: Wed, 19 Apr 2006 20:21:25 -0700
From: Mike Hoskins <mhoskins@...pen.com>
To: Brett Glass <brett@...iat.org>
Cc: bugtraq@...urityfocus.com
Subject: Re: Strengthen OpenSSH security?

Brett Glass wrote:
> It seems to me that sshd should not tip its hand by returning different 
> responses when a user ID can be used for logins than when it can't -- 
> allowing an attacker to focus password guessing attacks on user IDs with 
> which it would have a chance of gaining access. For those folks out 
> there who are more familiar with OpenSSH than I am: How hard would it be 
> to make the responses indistinguishable?

This has been a known issue for some time (Google), so I guess it's 
about time someone started using it rather than the usual "a, aa, aaa, 
aba, abb, ... zzzzzzzzz" type attacks I usually see.  Those always make 
me laugh.

While I agree with your point, I'm not versed enough in the SSH protocol 
(and don't feel like Googling again myself) to know if there's a 
technical reason (timing, etc.) that this behavior exhibits itself. 
This should raise an interesting discussion.

FWIW, I found that this sort of enumeration was possible myself when 
researching 2-factor authentication with OpenSSH.

That being said, I'd suggest configuring 2-factor authentication for any 
truly critical SSH gateways into your network.  If you don't want to 
dole out the cash for key fobs (including the cash to purchase them 
again and again as employees break them with really creative excuses ;), 
you can use public keys as "something employees have" along with the 
usual password for "something employees know".  With two-factor enabled, 
having either the key (stolen laptop) or the password (successful 
dictionary attack) won't permit access and will log the attempt.

http://bugzilla.mindrot.org/show_bug.cgi?id=983

Have been using this patch against the latest OpenSSH-stable release for 
awhile now along with appropriate log watchers, and getting a bit more 
sleep at night.

--Mike