brute force prevention - Githubissues

thesuperzapper commented 1 month ago

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

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.
- https://github.com/dexidp/dex/blob/677ab3602040a05f335c651d1d8ae0b6938ec9a7/server/server.go#L466
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)

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.

No response

No response

thesuperzapper commented 1 month ago

@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 commented 1 month ago

@thesuperzapper hello and thanks for pointing this. Our previous conversation ended in https://github.com/dexidp/dex/issues/1970

dexidp / dex