brute force prevention

[thesuperzapper]

Preflight Checklist

• I agree to follow the Code of Conduct that this project adheres to.
• I have searched the issue tracker for an issue that matches the one I want to file, without success.

Problem Description

Related: #2319
Related: #1869
Related: #1671
Related: #2454

We should introduce some way of preventing brute force attacks on the following areas:

• Static DB Login:
  • Unless the person hosting dex is doing some kind of brute force detection, this would be a relatively straightforward attack.

  • dex/server/server.go

    Line 466 in 677ab36

    func (db passwordDB) Login(ctx context.Context, s connector.Scopes, email, password string) (connector.Identity, bool, error) {

• OAUTH Static Client Secret:
  • Attackers could brute force client secrets, and once they figure one out, they can impersonate that client.
  • (This is a more sophisticated attack, and would require many other steps to exploit once the secret is obtained)
• LDAP Login:
  • Because we make requests to LDAP on behalf of the user, this could also be used for brute force.
  • (Unless the LDAP has its own "account locking" system)

Proposed Solution

I can think of a few possible ways to approach this (and we might need to do more than one):

• Introduce a "per-account lock" feature for Static DB Login:
  • After a certain number of failed login attempts, the account should be either temporarily or permanently locked.
  • If this is a permanent lock, we need to create some system for admins to "unlock" the accounts.
• Implement a CAPTCHA system, directly in dex:
  • After too many attempts on a specific "static db login", we could just require all attempts on that account to complete a CAPTCHA.
• In an HTTP response header, give information how many attempts have been made against this specific account in the last XXXX period:
  • The goal of this would be for a proxy sitting in front of dex to strip this header out, and use it to determine if it should block the client.
  • It could also be used in the reverse way, by allowing a proxy to set an extra request header to say "Please lock this account".
• Introduce a "Client ID" header, which proxies can set to identify clients (to dex) in whatever way they like:
  • Dex can then create action limits per each "Client ID", to prevent too many password or secret attempts.
  • Once the "action limit" is reached, we can respond 429, and eventually just block that client and not respond.
  • We could even "fail to ban" some clients and stop responding to them at all.
  • We could also request "additional verification" (in a response header) when we see suspicious activity. The outer proxy might then display a CAPTCHA to the user before allowing them to continue.

I am sure there are other options, please feel free to raise them.

Alternatives Considered

No response

Additional Information

No response

[thesuperzapper]

@nabokihms @sagikazarmark I am very interested in your thoughts because it's a pretty large security risk that users currently have to work around.

[nabokihms]

@thesuperzapper hello and thanks for pointing this. Our previous conversation ended in #1970