Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

brute force prevention #3509

Open
2 tasks done
thesuperzapper opened this issue May 6, 2024 · 2 comments
Open
2 tasks done

brute force prevention #3509

thesuperzapper opened this issue May 6, 2024 · 2 comments

Comments

@thesuperzapper
Copy link
Contributor

thesuperzapper commented May 6, 2024

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.
    • 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
Copy link
Contributor Author

@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
Copy link
Member

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants