On Thu, Jul 21, 2016 at 12:31 PM, Selphie Keller <selphie.keller at gmail.com> wrote:> Ahh i see, just got up to speed on the issue, so seems like the issue is > 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 hashThe 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] https://anongit.mindrot.org/openssh.git/commit/?id=9286875a73b2de7736b5e50692739d314cd8d9dc -- Darren Tucker (dtucker at zip.com.au) GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860 37F4 9357 ECEF 11EA A6FA (new) Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement.
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 account 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 and 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 has no password could be an option. On 20 July 2016 at 20:48, Darren Tucker <dtucker at zip.com.au> wrote:> On Thu, Jul 21, 2016 at 12:31 PM, Selphie Keller > <selphie.keller at gmail.com> wrote: > > Ahh i see, just got up to speed on the issue, so seems like the issue is > > 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] > https://anongit.mindrot.org/openssh.git/commit/?id=9286875a73b2de7736b5e50692739d314cd8d9dc > > -- > Darren Tucker (dtucker at zip.com.au) > GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860 37F4 9357 ECEF 11EA A6FA (new) > Good judgement comes with experience. Unfortunately, the experience > usually comes from bad judgement. >
On Wed, Jul 20, 2016 at 09:02:57PM -0600, Selphie Keller wrote:> 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,Since committing that diff I've heard of people running in production with no root password (ie *LK*, !! or similar). It's about the same amount of code to search for the first account with a valid salt, which would avoid this problem in the case where the root account doesn't have a real password. djm: what do you think? diff --git a/openbsd-compat/xcrypt.c b/openbsd-compat/xcrypt.c index 8913bb8..5385243 100644 --- a/openbsd-compat/xcrypt.c +++ b/openbsd-compat/xcrypt.c @@ -78,14 +78,18 @@ pick_salt(void) if (salt[0] != '\0') return salt; strlcpy(salt, "xx", sizeof(salt)); - if ((pw = getpwuid(0)) == NULL) - return salt; - passwd = shadow_pw(pw); - if (passwd[0] != '$' || (p = strrchr(passwd + 1, '$')) == NULL) - return salt; /* no $, DES */ - typelen = p - passwd + 1; - strlcpy(salt, passwd, MIN(typelen, sizeof(salt))); - explicit_bzero(passwd, strlen(passwd)); + setpwent(); + while ((pw = getpwent()) != NULL) { + passwd = shadow_pw(pw); + if (passwd[0] == '$' && (p = strrchr(passwd+1, '$')) != NULL) { + typelen = p - passwd + 1; + strlcpy(salt, passwd, MIN(typelen, sizeof(salt))); + explicit_bzero(passwd, strlen(passwd)); + goto out; + } + } + out: + endpwent(); return salt; } -- Darren Tucker (dtucker at zip.com.au) GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860 37F4 9357 ECEF 11EA A6FA (new) Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement.
> 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 dummyaccount> 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 DESand> 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 roothas> 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 password # If set to SHA512, SHA512-based algorithm will be used for encrypting password # If set to DES, DES-based algorithm will be used for encrypting password (default) # Overrides the MD5_CRYPT_ENAB option # # Note: It is recommended to use a value consistent with # the PAM modules configuration. # ENCRYPT_METHOD SHA512 /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 for: * 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 effects) * 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 error. Roman> On 20 July 2016 at 20:48, Darren Tucker <dtucker at zip.com.au> wrote: > > > On Thu, Jul 21, 2016 at 12:31 PM, Selphie Keller > > <selphie.keller at gmail.com> wrote: > > > Ahh i see, just got up to speed on the issue, so seems like the issueis> > > 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] > > > https://anongit.mindrot.org/openssh.git/commit/?id=9286875a73b2de7736b > 5e50692739d314cd8d9dc-------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6344 bytes Desc: not available URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20160721/8f5b7bfd/attachment.bin>