Optimistic Concurrency Control pattern from documentation sometimes lets conflicting writes go through?

Bug description

Context: I’m building a one-time-password login scheme that generates a 6 digit password and emails it to the user. To prevent brute force attacks, I’m locking an account for 24 hours after 5 failed attempts. So it’s really important that attackers don’t get more attempts to crack a password if they send a lot of requests concurrently.

I’m using the Optimistic Concurrency Control pattern shared in the documentation. But seeing that when I write a simple test that makes a bunch of attempts to login concurrently, some conflicting updates are allowed through.

How to reproduce

Repo with code to reproduce the problem: https://github.com/calebmer/prisma-optimistic-concurrency-control-pattern-conflict-repro

Run node repro.js a couple times. I have an assert with the expected output and it fails for me maybe 2 out of 3 times.

I tried to make a minimal reproducing case, but didn’t remove my domain model. (So the repro is still in the context of one-time-password login.)

Expected behavior

The repro code attempts to login 16 times with incorrect passwords. We should only expose to an attacker that the password was incorrect 5 times and then tell the attacker the account is locked 11 times. (An assert encodes this expectation.)

I don’t have the code for a “successful” login, but it also uses the Optimistic Concurrency Control pattern and is subject to the same conflicting write issue (which I’ve observed in local tests), effectively giving attackers more attempts to crack the password.

Prisma information

(Prisma schema, version, and queries included in the repro.)

Environment & setup

• OS: MacOS
• Database: PostgreSQL
• Node.js version: v15.0.1
• Prisma version:

prisma               : 2.21.2
@prisma/client       : 2.21.2
Current platform     : darwin
Query Engine         : query-engine e421996c87d5f3c8f7eeadd502d4ad402c89464d (at node_modules/@prisma/engines/query-engine-darwin)
Migration Engine     : migration-engine-cli e421996c87d5f3c8f7eeadd502d4ad402c89464d (at node_modules/@prisma/engines/migration-engine-darwin)
Introspection Engine : introspection-core e421996c87d5f3c8f7eeadd502d4ad402c89464d (at node_modules/@prisma/engines/introspection-engine-darwin)
Format Binary        : prisma-fmt e421996c87d5f3c8f7eeadd502d4ad402c89464d (at node_modules/@prisma/engines/prisma-fmt-darwin)
Default Engines Hash : e421996c87d5f3c8f7eeadd502d4ad402c89464d
Studio               : 0.371.0

[calebmer]

For more details on my actual code, the “successfully verified password branch” looks something like this:

const updateAccountResult = await prisma.account.updateMany({
  where: {
    id: account.id,
    // Include `failedOneTimePasswordLoginAttempts` in our `where` clause
    // because if it changed concurrently then the account may actually
    // be locked so we’ll want to skip the update.
    failedOneTimePasswordLoginAttempts:
      account.failedOneTimePasswordLoginAttempts,
  },
  data: {
    // Unset the one time password after it has been successfully used to
    // guarantee it won’t be used again.
    oneTimePasswordLoginHash: null,
    // Reset failed login attempt fields after successful login.
    failedOneTimePasswordLoginAttempts: 0,
  },
});

So it uses the same OOC “check” in the where clause but doesn’t need to atomically update any values. I’ve also observed this branch incorrectly fire when testing locally. (Naturally this is the dangerous branch to incorrectly fire since it logs the attacker in.)

[matthewmueller]

Closing. Happy to re-open this discussion if needed though.