Dmitry Belyavskiy
2023-Apr-12 09:55 UTC
Defend against user enumeration timing attacks - overkill
Dear colleagues, I have a question about this commit: https://github.com/openssh/openssh-portable/commit/e9d910b0289c820852f7afa67f584cef1c05fe95#diff-a25e40214ca9c9f78abce22f23bf2abdb2a24384c6610d60bbb314aed534eb48R216 The function ensure_minimum_time_since effectively doubles the time spent in the input_userauth_request (mostly presumably in PAM). So if PAM processing is really slow, it will cause huge delays - but if it is so slow, it's more difficult to perform the enumeration attack. So doesn't it make sense to provide an upper limit here and if really spent time is more than this upper limit, to avoid extra sleep? Will it be still necessary to protect from the attack? Vice versa, when the auth failure happens fast enough, the doubling will not significantly slow down the enumerations... Any comments will be highly appreciated! -- Dmitry Belyavskiy
Dmitry Belyavskiy
2023-Jun-28 11:51 UTC
Defend against user enumeration timing attacks - overkill
Dear colleagues, May I ask you to explain whether I am wrong in my conclusions? On Wed, Apr 12, 2023 at 11:55?AM Dmitry Belyavskiy <dbelyavs at redhat.com> wrote:> > Dear colleagues, > > I have a question about this commit: > > https://github.com/openssh/openssh-portable/commit/e9d910b0289c820852f7afa67f584cef1c05fe95#diff-a25e40214ca9c9f78abce22f23bf2abdb2a24384c6610d60bbb314aed534eb48R216 > > The function ensure_minimum_time_since effectively doubles the time > spent in the input_userauth_request (mostly presumably in PAM). So if > PAM processing is really slow, it will cause huge delays - but if it > is so slow, it's more difficult to perform the enumeration attack. > > So doesn't it make sense to provide an upper limit here and if really > spent time is more than this upper limit, to avoid extra sleep? Will > it be still necessary to protect from the attack? Vice versa, when the > auth failure happens fast enough, the doubling will not significantly > slow down the enumerations... > > Any comments will be highly appreciated! > > -- > Dmitry Belyavskiy-- Dmitry Belyavskiy