Nobody maintains this package

[animir]

I think, no one looks after this package anymore.

[AdamPflug]

... that's a nice opinion? I'm still around, but not actively developing new features for this at the moment.

I'm aware you're concerned about the issue with multiple concurrent requests from the same IP, and while I agree it's something that would be good to fix, it's a larger scope breaking change that would require re-working the storage plugin API as it currently exists. I also don't believe the current implementation represents a major security vulnerability for most sites, an attacker with many many concurrent requests might be able to squeeze a few extra requests in but they're still going to rapidly run into the rate limits (while at the same time all but guaranteeing that they get caught and flagged by other forms of brute force/ddos protection).

As noted in #46, my current thinking is that the logic for creating a unified interface and set of adapters for get/set/reset/etc for all the various cache storage mechanisms probably shouldn't be tightly coupled to a project like this. Instead it should be an independent project (something like waterline or consolidate.js but for memcached/redis/etc) that express-brute and other packages can delegate to. I haven't found a good existing candidate like this yet and also haven't had the time to develop one myself either.

I understand that you have your own dog in this race but aggressively marketing your library across github and posting negative stuff about other libraries isn't going to win you a lot of good will. I'd welcome productive suggestions or pull requests that help fix the problem if you're looking to make a positive contribution.

[animir]

@AdamPflug Hey, nice to see you around!

I felt, I was badass lier, after I had read the last paragraph.
I'm glad, I'm not!

This story is quite long. I'll concentrate on details, you may be interested in.

1. At some point, I did a small research about improvements would be useful for rate-limiter-flexible. I checked several packages in details and discovered, that express-brute uses get/set approach. I was curious, it was really issue or not, because I spent some time to implement atomic increments. I made several tests and realised, that I can do hundreds of password tries locally.

   Here is simple receipt: a) overload node event loop, so callbacks are added to queue before they are processed b) slow down counters store and c) instantly make thousands of requests with different passwords. You'd need 3 servers to make tests right.

   Then I did something interesting. I found, that Ghost project uses express-brute. They have many real clients, I made some research on their API and I was able to try 14 passwords instead of 5 from one MacBookPro sitting on other continent over mobile internet. I can't pin that ticket I created in Ghost repo, as they moved it to private repo.
   I think, it is easy to imagine, what hackers can do with 1000 servers.

   express-brute is added to known nodebestpractices repo. Here is related ticket 6.12 Recommended package express-brute does not do well on high traffic. Race conditions. goldbergyoni/nodebestpractices#329

2. Web security requires our attention. First of all, because not many small and middle projects/companies care about it.
   Additionally, node.js got low threshold of entry.
   And, we usually don't have time to check OS packages we use.
   It is our responsibility as maintainers to make our packages ready for all just listed above.

   I understand, that you don't have time to improve express-brute package. My positive contribution is this PR Add note about possible race conditions #80.
   Please, merge it.
   It has been hanging there for more than 3 weeks, that's why I decided, that nobody looks after this package.

[animir]

Regarding

it's a larger scope breaking change that would require re-working the storage plugin API as it currently exists.

You can use rate-limiter-flexible to implement desired logic. It would be easier, than developing everything from scratch.