Security in Nextcloud 12: Bruteforce Protection and Rate Limiting for developers

Post date

May 2, 2017

What’s new and improved

Nextcloud 11 introduced better password handling, CSP 3.0 and Same-site Cookies support improvements and expanded brute force protection. In Nextcloud 12, Bruteforce Protection can now be used by application developers to improve the protection of their application.

New in Nextcloud 12 is Rate Limiting. Rate Limiting can help protect servers from getting overloaded by broken apps and from users downloading too much data too quickly.

Improved: Brute Force Protection for apps

Brute Force Protection is meant to protect Nextcloud servers from attempts to guess user passwords in various ways. Besides the obvious “let’s try a big list of commonly used passwords” attack, it also makes it harder to use slightly more sophisticated attacks via the reset password form or trying to find app password tokens.

If triggered, brute force protection makes requests coming from an IP on a bruteforce protected controller with the same action slower and slower for a 24 hour period. The slow-down is up to 1 minute, slowly ramping up with increasing numbers of retries. One minute might not be much but slowing down retries from hundreds of times per second to 60 per hour effectively negates the danger of most brute force attempts. Triggers to the Brute Force Protection mechanism are stored in the database and result in a log entry so the admin can keep an eye on attempts at break in through brute force attacks.

Bruteforce protection can now be used by controllers of any app in a very easy way by adding an Annotation on a controller.
@BruteForceProtection(action=string)

string is the name of the action. Such as login or reset. Brute-force attempts are on a per-action basis; this means if a violation for the login action is triggered, other actions such as reset or foobar are not affected.

The throttle() method has to be called on the response in case of a violation. Doing so will increase the throttle counter and make following requests slower.

Find more details and an example controller method in the documentation.

New: Rate Limiting

Rate Limiting is a new security capability in Nextcloud 12. It allows a developer to specify how often an IP range or a user may send a request in a specific time period. This can be useful for expensive API calls, to prevent users from accessing too much data in a smaller attempt of time or harden bruteforce stuff further.

Rate limiting is currently only enabled if a memory cache is configured because every request is logged, requiring a potentially very large amount of database writes. Fallback to database may be added in the future, however the load on the database would be significant.

Like with Brute Force Protection, Rate Limiting can be enabled by adding Annotations to the controller:
@UserRateThrottle(limit=int, period=int) The rate limiting that is applied to logged-in users. If not specified Nextcloud will fallback to AnonUserRateThrottle.
@AnonRateThrottle(limit=int, period=int) The rate limiting that is applied to guests.

Rate limiting is only applied to the current controller method. So if the rate limit for one method is reached only the controller method will deliver a 429 status code.

More details and example code can be found in the documentation.

On Github, see a real life example on how rate limiting can be easily applied: Nextcloud Server pull request 4434.

Conclusion

As the above pull request shows, Rate Limiting and Brute Force Protection have been applied in the core Nextcloud code. We call on app developers to follow that example and implement these extra protections in their applications, making it even harder for adversaries to break the security of Nextcloud systems!