LG-311 Prevent bypassing account lockout when sending SMS verification codes

[stevegsa]

Why: An attacker can abuse the SMS system and spam users

How: Create an atomic increment on OtpRequestsTracker. Increment count before checking rate limit. Don't memoize the OtpRequestsTracker returned from the update. (3 fixes total). Testing will need to be done with Burp's repeater to hit idp with parallel requests.

Hi! Before submitting your PR for review, and/or before merging it, please
go through the following checklist:

• For DB changes, check for missing indexes, check to see if the changes
  affect other apps (such as the dashboard), make sure the DB columns in the
  various environments are properly populated, coordinate with devops, plan
  migrations in separate steps.

• For route changes, make sure GET requests don't change state or result in
  destructive behavior. GET requests should only result in information being
  read, not written.

• For encryption changes, make sure it is compatible with data that was
  encrypted with the old code.

• For secrets changes, make sure to update the S3 secrets bucket with the
  new configs in all environments.

• Do not disable Rubocop or Reek offenses unless you are absolutely sure
  they are false positives. If you're not sure how to fix the offense, please
  ask a teammate.

• When reading data, write tests for nil values, empty strings,
  and invalid formats.

• When calling redirect_to in a controller, use _url, not _path.

• When adding user data to the session, use the user_session helper
  instead of the session helper so the data does not persist beyond the user's
  session.

• When adding a new controller that requires the user to be fully
  authenticated, make sure to add before_action :confirm_two_factor_authenticated.

[jmhooper]

Could we use #update! in a #with_lock block here to prevent us from having to write SQL in our rails code.

[stevegsa]

We could do that but we get superior db performance without using locks especially as we scale up.

[jmhooper]

The lock would be per-row though right? So you wouldn't see perf issues unless you were trying to exploit this one?

[stevegsa]

Yes it would be row-level locking. It's not exactly free from the db's perspective (the cost of locking/unlocking) and those locks can add up as we scale up.

[davemcorwin]

what is the actual cause of the issue here? Is it that something is cached? why does hand-coding the update help?

[davemcorwin]

http://api.rubyonrails.org/classes/ActiveRecord/Persistence.html#method-i-increment!

[davemcorwin]

and can't we just make sure to read the value from the database when checking to see if the threshold is hit, then we should be gtg?

[davemcorwin]

I believe calling .reload on an active record model will bust the query cache

[stevegsa]

I'm incrementing the field and updating the rest of the record in one db write.

[davemcorwin]

yeah, that saves a step, perhaps we can add a comment here to explain why we are doing this?