on defeating timing-based account enumeration

[jf]

(NOTE: this is a semi-philosophical question. I am looking for opinions, thoughts, and feedback.)

This started out with me noticing that I get different error messages for different errors for the login page, revealing the specific error field ("no matching login" vs "invalid password"). I've read the response in https://groups.google.com/g/rodauth/c/5TToghHFvG4, which is related, but for reset password request.

Is it not possible to basically make any sort of attack constant-time? Leaving the architecture of the application server aside, what if we were to approach the target of constant-time by:

1. first of all, determining a target constant time
2. logging the start time when a request to a protected endpoint comes in
3. measuring the time it takes for our own internal answer to come back
4. adding however much sleep or wait time is needed to make it to the target constant time before replying?

Is this not feasible? I was glancing through another article, and one of the suggestions was to do account lockouts (so ceding enumeration then, in this case)... except that doesn't really help with password spraying. And I'm not sure that monitoring is a real solution either (you'd have to set up the infrastructure, plus hire the team to do the monitoring; and hope that they are that alert / good / conscientious).

[jf]

related to the topic (I'm trying to keep the number of discussions small), I tried the following code, modeled after the suggestion in https://groups.google.com/g/rodauth/c/5TToghHFvG4:

login_error_flash do
  set_field_error(login_param, nil)
  set_field_error(password_param, nil)
  set_notice_flash "boo"
end

... and I notice that I seem to be getting 2 flashes. For whatever reason, my flash becomes {"notice"=>"boo", "error"=>"boo"}

Is this a bug? If I do set_error_flash instead, there is no duplicate of the message in the flash ({"error"=>"boo"})

[janko]

FYI, there is more discussion around that here – https://groups.google.com/g/rodauth/c/U-xxqes-ur4/m/Z2xZ2TaEGgAJ.

[jf]

thank you! did not know that there's more, but this is helpful!

[jf]

one thing that the last answer in that thread does not cover: how do I get rid of the (helpful but also leaks info on the email) prompt and form to do a password reset?

Right now if I attempt to log in with a valid and verified login, but give the wrong password, I will get another form above login-form that says If you have forgotten your password, you can request a password reset:, and then a button underneath.

[jf]

after some debugging it looks like it's coming from #{rodauth.login_form_header} in templates/login.str... I'm not exactly sure how it gets filled though: it's an attr_reader in lib/rodauth/features/login.rb... The only (? correct me if I am wrong) possibility of it getting filled would be from def after_login_failure (and that's in lib/rodauth/features/reset_password.rb); but here I don't know how that gets called.

Also, I already have a after_login_failure in my plugin :rodauth block... and that does NOT call super(). Could somebody enlighten me please?

[jf]

ok, I got it. All that I surmised is true. The built-in after_login_failure is called, and before my own after_login_failure block. To get rid of that form, all I have to do is to do @login_form_header = '' (or nil). If I do not want to prompt the user to go to the reset password page (the reset password link is still available), this isn't a fatal error affecting anything else, right? I'm thinking not, but it would be good to get a confirmation.