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

No failed login limit #2579

Open
sevenlayercookie opened this issue Feb 4, 2024 · 2 comments
Open

No failed login limit #2579

sevenlayercookie opened this issue Feb 4, 2024 · 2 comments
Labels
bug Something isn't working

Comments

@sevenlayercookie
Copy link

Describe the issue

It is possible to submit any number of failed login requests without limit, and without rate limit. This makes Audiobookshelf susceptible to brute force login methods.

as @nichwall noted, this appears to have broken in v2.6.0 with OIDC implementation.

related issue: #2533 no auth log entries.

Steps to reproduce the issue

  1. Submit incorrect password as many times as you like.
  2. Login with your normal password immediately afterward without being locked out.

Audiobookshelf version

V2.7.2

How are you running audiobookshelf?

Docker

@sevenlayercookie sevenlayercookie added the bug Something isn't working label Feb 4, 2024
@Sapd
Copy link
Contributor

Sapd commented Feb 4, 2024

Probably was removed during the Auth/passport rerwite.

I think instead of implementing that directly, better would be a middleware:
https://www.npmjs.com/package/express-slow-down

Advantage is, it could be also used against other public API endpoints.

Also one should be able to turn it off. Some people like to user other means. Also some don't forward the Client IPs from their reverse proxies (which is at some architectures even by design). If the default suggestion is used it probably it is not needed to be configurable:

windowMs: 5 * 60 * 1000, // 5 minutes
	delayAfter: 5, // Allow 5 requests per 5 minutes.
	delayMs: (hits) => hits * 250

Because this way it does not block completely but adds a delay of 250ms. Should be enough to make every brute force attempt too slow, but still work with other configurations without forwarded IPs.

@bytebone
Copy link

bytebone commented Feb 6, 2024

No need to solve problems the complicated way. Just fix the logging component so that IPs of unsuccessful login attempts are in logfiles, and let users figure out how to handle this with fail2ban / crowdsec / whatever else.

I would much rather ban IPs that are consistently trying to bruteforce usernames / passwords, than allowing them to slowly but surely chip away at the login form.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

3 participants