I thought this was already addressed with the internal blowfish hash of "$2a$06$r3.juUaHZDlIbQaO2dS9FuYxL1W9M81R1Tc92PoSNmzvpEqLkLGrK" to where all passwords were checked against this to prevent timing analysis for user enumeration. On 20 July 2016 at 19:45, Darren Tucker <dtucker at zip.com.au> wrote:> On Tue, Jul 19, 2016 at 11:10 PM, C0r3dump3d <coredump at autistici.org> > wrote: > > Hi, sorry I don't know if I send this to the correct channel. > > It is. > > [..] > > it's possible in certain circumstances to provoke a DOS > > condition in the access to the ssh server. > > We have been discussing this a bit, and what we have just added is a > simple hard limit on the allowed size of a password string at 1k, > above which the password is immediately refused. There's other > possible embellishments (eg, add a possibly variable delay) but we > haven't decided on any yet. > > Thanks. > > -- > 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. > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev >
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, 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 from blowfish to sha to fix this for modern systems may invalidate it inversely on older systems, where this attack can be done to find the difference in the other direction of taking to long. Some sorta of hybrid solution of computing hashes based on what the system is actively using should resolve the timing issue. So if this is on a newer system using sha family for hashing it would use a sha family hash to be the fall back for accounts and blowfish if it's on a system using blowfish. On 20 July 2016 at 20:18, Selphie Keller <selphie.keller at gmail.com> wrote:> I thought this was already addressed with the internal blowfish hash of > "$2a$06$r3.juUaHZDlIbQaO2dS9FuYxL1W9M81R1Tc92PoSNmzvpEqLkLGrK" to where all > passwords were checked against this to prevent timing analysis for user > enumeration. > > On 20 July 2016 at 19:45, Darren Tucker <dtucker at zip.com.au> wrote: > >> On Tue, Jul 19, 2016 at 11:10 PM, C0r3dump3d <coredump at autistici.org> >> wrote: >> > Hi, sorry I don't know if I send this to the correct channel. >> >> It is. >> >> [..] >> > it's possible in certain circumstances to provoke a DOS >> > condition in the access to the ssh server. >> >> We have been discussing this a bit, and what we have just added is a >> simple hard limit on the allowed size of a password string at 1k, >> above which the password is immediately refused. There's other >> possible embellishments (eg, add a possibly variable delay) but we >> haven't decided on any yet. >> >> Thanks. >> >> -- >> 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. >> _______________________________________________ >> openssh-unix-dev mailing list >> openssh-unix-dev at mindrot.org >> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev >> > >
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.