When using lockable, failed_attempts is incremented by two after failed login attempt
When using devise-two-factor with devise lockable, there are somehow two calls being made to validate/valid_for_authentication? - the latter of which is doing the failed_attempts increment.
The first failed_attempts increment happens within this block, and the latter seems to be happening after the authenticate! method is finished executing.
if validate(resource) { !resource.otp_required_for_login ||
resource.valid_otp?(params[scope]['otp_attempt']) }
super
end
My devise initializer is configuring the warden strategy as follows:
config.warden do |manager|
manager.default_strategies(:scope => :user).unshift :two_factor_authenticatable
end
My user model is set up with devise as follows:
devise :two_factor_authenticatable, :otp_secret_encryption_key => ENV['RSA_KEY_PW'], otp_secret_length: 64
devise :registerable, :recoverable, :invitable, :trackable, :timeoutable, :lockable
When using lockable devise increments the failed_attempts counter by one right in the beginning of the authentication even though the authentication has not yet failed nor succeed. It happens in lib/devise/models/lockable.rb method valid_for_authentication?
To be more accurate it is the current_user and user_signed_in? helpers that are trying to authenticate the user from the request data. If none of those helpers are called during the authentication action then the failed_attempts counter is not increased.
@ShaneWilton could you look at this when you get a chance? This is a rather tricky bug.
@mwalsher, @mmustala, @ShaneWilton guys, any update on that?
Two years elapsed, any progress?
Any progress? Been hitting a wall and was wondering if it was me or devise or devise-two-factor
another issue #127 still not fixed :(
I'm facing the same issue as well. Our hacky fix was just to double the maximum_attempts to what we really want. (ie. we want to lock after 10 failed attempts, so we set maximum_attempts to 20)
Any update on this issue? I've been doubling the maximum_attempts to hack my way in as @StevenJL.