Suggestion: Implement 2FA, CAPTCHA, Login IP Logging & Management, and Recovery Options

[mpopui]

Suggestion: Implement 2FA, CAPTCHA, Login IP Logging & Management, and Recovery Options

Problem Statement
Open WebUI currently lacks key security features such as two-factor authentication (2FA), CAPTCHA, and IP logging, leaving devices exposed to brute-force attacks and external scanning tools like Censys, which constantly scan public IPs. Once an attacker has credentials, they can easily break in, posing a serious risk to both public and private servers. Strengthening security is essential to ensure safe operation of both public service instances and private systems.

Proposed Features

1. Two-Factor Authentication (2FA)

   • TOTP 2FA: Add support for two-factor authentication using Google Authenticator or any other compatible TOTP (Time-Based One-Time Password) solution. This ensures that even if someone gains access to the password, they still need a second authentication step.
   • Alternative 2FA Methods: In addition to TOTP, provide alternative methods like email-based one-time codes (OTC). This method sends a code to the user’s email, which they must enter to complete the login process.
   • Recovery Keys: Introduce recovery keys for 2FA. When users set up 2FA, they should be provided with a recovery key that can be used to regain access to their account if they lose access to their authentication device.

2. CAPTCHA for Login Protection

   • Add a CAPTCHA system on the login page to prevent automated brute-force attacks. Provide multiple options for CAPTCHA implementation:
     • Offline Open-Source CAPTCHA: For environments with no external dependencies.
     • Popular Third-Party CAPTCHAs:
     • Google reCAPTCHA
     • Cloudflare Turnstile
     • Other open-source CAPTCHA tools
   • The admin interface should allow easy selection of the CAPTCHA type and API key integration, similar to how search engines are configured.

3. Login IP Logging & Management

   • Enable logging of login attempts, recording details such as IP address, timestamp, and geolocation for each successful and failed attempt.
   • Allow administrators to review these logs through the admin panel, helping them detect suspicious login behavior.
   • Introduce IP management with features to configure:
     • IP Whitelists: Define specific IP ranges allowed to log in.
     • IP Blacklists: Block login attempts from certain IP addresses or regions, adding an extra layer of security.

4. Email Integration

   • To enable email-based 2FA (one-time codes) and account recovery, an email notification system should be implemented. This feature would allow the system to send:
     • Verification codes during login for email-based 2FA.
     • Recovery emails for users who need to regain access to their account.
     • Alerts to notify users and administrators of suspicious login attempts or account changes.

Conclusion
By adding 2FA (with multiple recovery options), CAPTCHA, IP logging, and email integration, Open WebUI will significantly enhance its security framework. These features will mitigate the risk of brute-force attacks and unauthorized access, ensuring safer operation for both public and private instances.

[thiswillbeyourgithub]

Captcha would mean adding dependencies. Email would need to include a server and would end up in spam for most users not properly setup no? For IP logging and whitelist and blacklist I agree, although I setup fail2ban on my own.

Isn't there some container that does most of this very well to start with that we could just add in the docker ? In general it's poor practice to reimplement security features diy instead of using battle tested solution. No? Kina like the reason why there's no builtin https : it would give a false sense of security and many youngster would expose it to the internet withno protection.

Edit: But I think it would be beyond great if someone would give an in-depth tutorial on how to set up an advanced login system with those features using Docker compose around Open Web UI.

[mpopui]

Thank you for your response! I understand your concerns about the dependency on CAPTCHA, mail systems, and other security functions and their implementation complexities. Indeed, relying too much on external tools for security measures can introduce complexity and even potential risks. However, I'd like to give a practical example to illustrate the importance of these features—Nextcloud, an open-source personal cloud storage system. It has powerful built-in security features, including 2FA, CAPTCHA, IP management, and email notifications. These features not only protect the system from external attacks but can also be enabled or disabled as needed. Nextcloud's design approach is worth considering.

For most home broadband users, they are typically not directly exposed to the public internet, as in many countries, home broadband does not come with a public IP. In such cases, it's reasonable to have these security features turned off by default. Only a small number of users need to be exposed to the public network, and they often use NAT traversal (like Peanut Shell) and IPv6+DDNS. However, these users often know how to secure their systems and have a certain level of technical expertise. But for those running on cloud servers, exposure to the public network is unavoidable, so providing them with additional security options is essential.

Take Ollama as an example; many users actually run the API locally rather than exposing the Ollama model's public interface. These users often use NVIDIA GTX 4090 graphics cards and run the Open WebUI through Windows' WSL2 environment. Such users typically use home broadband, and in many countries, home broadband lacks a public IP, so they are hardly exposed to the public network. For the few users with high security demands, they also use the installation offline, completely avoiding public network risks. So, indeed, some users don't need to worry about security issues.

However, for users truly exposed to the public network, whether using Ollama or other services, security becomes crucial. In a public network environment, as long as someone knows their IP address or domain name, theoretically anyone can call these interfaces. In this situation, relying on external WAFs (like NGINX proxy or Cloudflare WAF) can provide some degree of protection but cannot completely avoid vulnerabilities or dependency issues. Just like open-source software cannot guarantee absolute security, but publicly auditing the source code can ensure transparency and safety to a large extent.

With built-in security functions, we can let users choose whether to enable these protective measures. For those exposed to the public network, providing features like 2FA, CAPTCHA, IP whitelists and blacklists, and email notifications can effectively enhance system security, reducing the complexity of relying on external tools. Meanwhile, these features are turned off by default, allowing users who need them to enable them. This not only makes the system more flexible but can also adapt to various usage scenarios—whether it's LAN users, offline users, or advanced users on cloud servers, all can receive the necessary security protection.

When designing Open WebUI, we can draw inspiration from mature open-source projects like Nextcloud to balance security and operability. Integrating these features won't excessively increase dependency; rather, it can make the whole system more resilient, reducing potential risks from external services.

I hope you'll consider these viewpoints, as user scenarios are diverse, and we need to provide flexible and secure options for users with different needs.

[thiswillbeyourgithub]

Just to clarify: i'm not the owner, just a regular user.

And I disagree with your comparison with nextcloud as there are at least 2 orders of magnitude of difference in the development team sizes with respect to open-webui.

Curious what the owner of this repo will think of this.