> 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 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. 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@xxxxxxxxxx> wrote: > > > On Thu, Jul 21, 2016 at 12:31 PM, Selphie Keller > > <selphie.keller@xxxxxxxxx> 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=9286875a73b2de7736b > 5e50692739d314cd8d9dc
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
