AW: Openssh use enumeration

Fiedler Roman Roman.Fiedler at
Thu Jul 21 17:59:53 AEST 2016

> From: openssh-unix-dev 
> I wonder if could be useful to set the fall back account to something user
> defined to avoid suggesting people add passwords to root, though I do like
> root since the account is always there, but I myself would do that invalid
> pass before actually adding a real pass to root, however I think it would
> be nice if there was a sshd_config option for fallback_timing_account to
> let the user specify something other then root like some generic user they
> already have that doesn't involve root. Or have ssh create an dummy
> on the system that has only a invalid password. The fall back to DES seems
> ok, but not sure it would fully resolve the issue, since timing for DES
> sha family would be different, but does fix the instant fail for crypt not
> understanding blowfish. The random delay idea is pretty good it would make
> timing analysis difficult. I wonder if DES + random delay in event root
> no password could be an option.

Why not use the settings from /etc/login.defs?

 # If set to MD5 , MD5-based algorithm will be used for encrypting password
# If set to SHA256, SHA256-based algorithm will be used for encrypting
# If set to SHA512, SHA512-based algorithm will be used for encrypting
# If set to DES, DES-based algorithm will be used for encrypting password
# Overrides the MD5_CRYPT_ENAB option
# Note: It is recommended to use a value consistent with
# the PAM modules configuration.

/usr/bin/passwd from "shadow" package goes down the same way when setting
passwords. So perhaps following code would be hard to do timing analysis

* Get default hash method from login.def
* Get/create a fake crypted passwd for the method/salt being default.
* Get the pwent for the user name requested
* When user not found: get the entry for root and discard the result
* When user check succeeded: get the entry for the user "nonexisting:xxxx" -
I think ':' is forbidden, so name should never exist (TODO: check side
* Compare the supplied passwd with the fake or real hash
* Do what has to be done.

What do you think? Only easy timing attacks should be on systems where
DefaultMethod!=all password methods, which could be deemed a configuration


> On 20 July 2016 at 20:48, Darren Tucker <dtucker at> wrote:
> > On Thu, Jul 21, 2016 at 12:31 PM, Selphie Keller
> > <selphie.keller at> wrote:
> > > Ahh i see, just got up to speed on the issue, so seems like the issue
> > > related to blowfish being faster then sha family hashing for longer
> > length
> > > passwords,
> >
> > or the system's crypt() not understanding $2a$ -style salts, which
> > most glibcs don't.  On those, crypt fails immediately due to invalid
> > salt.
> >
> > > so there is a time lag difference between the blowfish internal
> > > hash and the sha family hash, though this could be tricky to fix since
> > some
> > > systems may still use blowfish based hashing and changing the internal
> > hash
> >
> > The best I could come up with (which is what I implemented[1]) was to
> > look the crypt method used for root's password and use that, falling
> > back to DES if that fails.  That scheme won't help if you don't set a
> > root password (or set it to *LK* or similar), but short of surveying
> > all accounts on the system I'm not sure how to do much better.
> >
> > [1]
> >
> 5e50692739d314cd8d9dc

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6344 bytes
Desc: not available
URL: <>

More information about the openssh-unix-dev mailing list