Hi, does anyone have insights on a question from our IT security department? They asked whether Specify 7 software includes a failed login attempt limit and a timeout security feature. If so, is this setting configurable? I’m specifically referring to the integrated basic SP-7 user authentication mechanism, not the SSO authentication option. Thanks
Hi @Heryk,
Specify does not currently offer a limit on failed login attempts or a timeout feature. Is this something your IT security department would be interested in using if it becomes available?
Thank you!
1 Like
Hi @grant,
Thank you for your incredibly quick response! Yes, this is a significant concern they’ve raised. To avoid potential roadblocks from IT due to this issue, I plan to emphasize that our instance of SP-7 is not public-facing. However, if we can properly address this IT concern, it would be greatly appreciated.
Thanks!
1 Like
@Heryk, I wonder if this isn’t something that would be better applied at the firewall level (or maybe even at the web server level in nginx).
In a personal capacity, I use a Web Application Firewall for my servers and it works quite well for rate limiting and denying bots, and the University runs something similar. This usually has the added bonus of protecting you from DDoS attacks at the same time, because those systems are setup to handle a lot of load. Perhaps the IT team is unable to do this easily because these services are configured mostly for internet facing applications? I don’t know as much about internal networking
Within Django, it looks like there is a middleware option for a decorator that would enable rate limiting, but the base django documentation didn’t come up when I did a quick DDG.
2 Likes
Thanks for your feedback. So, the key point here seems to be if whether security features such as DDoS protection, authentication limits, and request throttling should be integrated into SP-7 or left to clients to implement via external security layers.
From what I understand, here are some key considerations…
Advantages of Including Security Within SP-7
- Consistency Across Deployments
- Ensures all users benefit from a baseline security standard, reducing the risk of misconfigurations.
- Ease of Deployment & Maintenance
- Reduces IT burden for organizations with limited security expertise.
- Security patches and updates can be managed within the software, ensuring protection is up-to-date.
- Integrated Logging & Monitoring
- Provides centralized tracking of security incidents, such as failed login attempts and brute-force attacks.
- Enables faster incident response and security monitoring within the application.
- Better Compatibility & Control
- Ensures security measures (e.g., rate limiting, authentication rules) are fully compatible with the application’s logic.
- Avoids conflicts that may arise when integrating external security tools.
Advantages of Relying on an External Security Layer
- Flexibility for Clients
- Organizations can implement security tailored to their infrastructure and policies (e.g., enterprise authentication providers, firewall configurations).
- Leverage Cloud & Network-Based Security Solutions
- Many enterprises already use advanced security services (e.g., AWS WAF, Azure DDoS Protection) that are more sophisticated than built-in security.
- Separation of Concerns
- Allows SP-7 development to focus on feature enhancements while security is handled by dedicated tools and infrastructure.
Recommendation: A Hybrid Approach?
To balance efficiency and flexibility, Specify should maybe adopt a hybrid security approach?
- Include Fundamental Security Features in SP-7
- Implement authentication limits, request throttling, and basic DDoS protection within the application.
- Provide built-in logging for security events to enhance monitoring.
- Allow Clients to Implement Additional Security Layers
- Provide configuration options to enable or disable built-in security features based on deployment needs.
- Ensure compatibility with external security solutions for organizations requiring advanced protection.
Benefits of This Approach
- Lower IT Overhead – Small to mid-sized users can rely on built-in security without requiring external expertise.
- Faster Incident Response – Centralized security logs enable quick identification of threats.
- Improved User Experience – Reduces setup complexity for users who prefer a straightforward deployment.
By integrating essential security within SP-7 while allowing for external security layers, we can achieve a secure yet flexible deployment model suitable for a wide range of users.
What are your thoughts? Is there anything I might have overlooked in my understanding of the situation?
Thanks
Hi @Heryk,
Perhaps the highest marginal add that would solve most (though not all) of the objectives, would be the integration of TOTP on the Specify login (passkeys, another alternative, were opened for suggestion here). This provides a couple of benefits that address your points, while also being easier to implement. TOTP is almost always done at the application level, so it is a better fit, while not interfering with rate limiting or DDoS that is done at the network level. There are django packages that are designed for this purpose, as it is a common feature to implement.
This could be enabled on all deployments by default as it would ship with the source code, raising the baseline security standard by quite a bit. There would be no integration or things to configure for an IT team, it would work out of the box.
If Specify was to implement rate limiting, perhaps it’s better that we think about it not from the traditional sense (limiting requests as they come into the web server), but setting a maximum amount of incorrect guesses that can be made before the user is locked out, requiring the admin to click a button in the. security and accounts menu to reset the counter. This could be done for either the user/login, TOTP, or both. Of everything in this discussion, a failed login counter on the current login is probably the easiest to implement.
One downside to this approach, is that I can now deny someone access to their account pretty easily, all I need to do is head to the instance, and fail the login attempts a few times and they won’t be able to login. Thus, I would suggest it be done at the TOTP layer if done at all.
Most attackers these days will use phishing rather than trying to brute force a login page, because a brute force is noisy and most servers will have some method in place to automatically reject it and then ban the IP (or at least, put it on a timeout).
2 Likes
Hi @markp,
I fully agree with your points and suggestions. I truly appreciate your valuable insights—thanks again!
Hi @markp,
I’ve added your comment to the passkey suggestion. We’ll consider it when we look to further develop the Specify login system! Thank you so much for your feedback and suggestions!
1 Like