Request limiting for authentication

[molomby]

There's no obvious/good/easy way right to prevent attackers from hammering an a Keystone app attempting to brute force a login. The use of bcrypt for password offers very slight protection (in so far as, if you're getting bruteforced, you'll hopefully notice a massive spike in load) but there's nothing to actually block/throttle requests.

Solution developers can deploy tools like fail2ban in front of their app servers but, given the nature of GraphQL, it's difficult to target specific queries/mutations. Solutions like this also complicate deployments and aren't workable for some platforms (Heroku, Now, etc.).

We should be secure by default and getting a basic fix for this in place, with reasonable defaults, shouldn't be too hard.

[molomby]

@jesstelford has suggested it..

.. might make more sense to do right in the authentication provider [eg. Password], so it works for the GraphQL API also.

[MadeByMike]

I'm not sure this should be a Keystone concern. Services like fail2ban do a good job of this because it is their main focus. Do we want to own that too?

If they are difficult to configure or set-up for specific situations such as graphQL don't they need to improve support for this rather than us?

I think the most we should do is provide a good set-up guide? Or allow someone to develop this as a contrib plugin.

@JedWatson mentioning you here because I think you also have feels about what the scope of Keystone should be.

[sarneaud]

@MadeByMike Fail2ban is an option for VPS deployments. It isn't a general solution for other deployment environments like a PaaS (Heroku, etc.) or a functions-as-a-service offering, though. I think password rate limiting is expected to be in-app by those environments (how it gets installed/enabled is a totally different question).

Here's some discussion (and bikeshedding) for Drupal (which makes rate limiting a core feature):
https://www.drupal.org/project/drupal/issues/485974

An external plugin is used in Django.

[adrianbienias]

Are there some suggested ways to handle multiple failed login attempts with Keystone?

[dcousens]

@adrianbienias you can implement this as part of your own session management, using the database as needed for whatever your heuristics are. Keystonejs does not currently provide an opinionated solution out of the box.

[adrianbienias]

Can I somehow hook to the provided by Keystone authentication system?

There are hooks available for schemas, but I can't find a way to trigger my custom function before authenticating.
I can create a field in User model for storing failed login attempts.
But I need a way for checking that field during login attempts and block them when failed login attempts go above a threshold.

[adrianbienias]

I found HOOKS.md describing what I'm looking for, but I have no idea how to use those auth hooks based on that document.

Also, I see a merged PR #2039 but I don't get why there's nothing in documentation about those hooks.

[dcousens]

@adrianbienias both of those references are out of date and not representative of the code now.
Keystone 6 has an @keystone-6/auth package, but that package is highly opinionated and might not be what you use for your project.

What exactly did you want to do?

I need a way for checking that field during login attempts and block them when failed login attempts go above a threshold.

By returning a GraphQL error? Or by returning a 429 response?

[adrianbienias]

What exactly did you want to do?

I want to have a secure auth in terms of being resistant to a brute force attacks.

Magic link login sounds perfect for me and @keystone-6/auth seems to support it, but I have no idea how to change the default /signin form to the one that handles that.

Also, secretField seems like a mandatory field so handling magic link signing in, doesn't disable using password.

As you said, @keystone-6/auth is highly opinionated, and I guess doesn't suit my needs.

Then the question becomes - how I can use an alternative way for authentication?

How to implement my own instead of @keystone-6/auth?

How to create a login page that is not part of the admin panel?

How to create sessions, so I can use them for handling schema.ts access rules?

Basically, I'm in the point where I have my own CMS using Prisma + Next.js + NextAuth, but I decided to check Keystone because of the auto generated API and fully functional admin panel features (searching, filtering, adding, editing, creating, etc.) that I don't have implemented in my CMS in that scale.

I thought Keystone is a perfect replacement and is going to save me some work, but right now after a week of getting to know Keystone, I learned it doesn't support auth in a way that is acceptable for me, thus tailoring it to my needs is also going to take a lot of work.

[luuhung93]

Authenticator, maybe, expected ,

[StefanNemeth]

Just for reference, here is how I implemented it using a custom Apollo Server middleware, rate-limiter-flexible and graphql-armor (to prevent alias bruteforce attacks):

import { ApolloArmor } from '@escape.tech/graphql-armor'
import { applyMiddleware } from 'graphql-middleware'
import { RateLimiterMemory } from 'rate-limiter-flexible'

const rateLimiter = new RateLimiterMemory({
  points: 5, // Maximum number of failed attempts
  duration: 15 * 60, // Per 15 minutes
  blockDuration: 15 * 60 // Block for 15 minutes after exceeding points
})

const withBruteforceProtection = {
  Mutation: {
    authenticateUserWithPassword: async (resolve, root, args, context, info) => {
      const ip = context.req.ip
      const key = `${ip}`

      try {
        // Consume 1 point for this attempt
        await rateLimiter.consume(key)

        const result = await resolve(root, args, context, info)

        // If authentication succeeded, reset the rate limiter for this key
        if (result?.sessionToken) {
          await rateLimiter.delete(key)
        }

        return result
      } catch (err) {
        if (err instanceof Error) {
          throw err
        } else {
          throw new Error('Too many failed attempts. Please try again later.')
        }
      }
    }
  }
}

export default withAuth(
  config({
    // ....
    graphql: {
      apolloConfig: {
        ...armor.protect()
      },
      extendGraphqlSchema: (schema) => {
        return applyMiddleware(schema, withBruteforceProtection)
      }
    }
  })
)

For the sake of simplicity, it's using the in-memory RateLimiter, which could be changed to RateLimiterPrisma, RateLimiterRedis, etc. I'm pretty sure there is a better way to do this, but it works well for my use-case :)