starred/uptime-kuma

Fork 0

mirror of https://github.com/louislam/uptime-kuma.git synced 2026-03-02 22:57:00 -05:00

Possible bug? #3830

New issue

Closed

opened 2026-02-28 03:42:16 -05:00 by deekerman · 8 comments

deekerman commented

2026-02-28 03:42:16 -05:00

Owner

Originally created by @merlin3of5 on GitHub (Dec 13, 2024).

None that I know for certain are related.

🛡️ Security Policy

I agree to have read this project Security Policy

Description

The web gui was rejecting my login even after resetting my password. I went searching though open issues trying to find a solution but only found old closed cases with no solution. The problem I was having is that the username is case sensitive and my username was stored in my password manager without the matching uppercase characters. I am not certain if this counts as a "bug" but thought I would post for anyone else having a similar issue.

👟 Reproduction steps

Create a new login and use capitalization in the username. Then try logging in with all lowercase in the username.

👀 Expected behavior

Normally, I would expect the username field to not be case sensitive.

😓 Actual Behavior

Username field is case sensitive.

🐻 Uptime-Kuma Version

1.23.15

💻 Operating System and Arch

Docker

🌐 Browser

Firefox 133.0.3

🖥️ Deployment Environment

Runtime: Docker 24.0.7
Database:
Filesystem used to store the database on:
number of monitors:

📝 Relevant log output

No response

Originally created by @merlin3of5 on GitHub (Dec 13, 2024). ### 📑 I have found these related issues/pull requests None that I know for certain are related. ### 🛡️ Security Policy - [X] I agree to have read this project [Security Policy](https://github.com/louislam/uptime-kuma/security/policy) ### Description The web gui was rejecting my login even after resetting my password. I went searching though open issues trying to find a solution but only found old closed cases with no solution. The problem I was having is that the username is case sensitive and my username was stored in my password manager without the matching uppercase characters. I am not certain if this counts as a "bug" but thought I would post for anyone else having a similar issue. ### 👟 Reproduction steps Create a new login and use capitalization in the username. Then try logging in with all lowercase in the username. ### 👀 Expected behavior Normally, I would expect the username field to not be case sensitive. ### 😓 Actual Behavior Username field is case sensitive. ### 🐻 Uptime-Kuma Version 1.23.15 ### 💻 Operating System and Arch Docker ### 🌐 Browser Firefox 133.0.3 ### 🖥️ Deployment Environment - Runtime: Docker 24.0.7 - Database: - Filesystem used to store the database on: - number of monitors: ### 📝 Relevant log output _No response_

deekerman

2026-02-28 03:42:16 -05:00

closed this issue
added the
bug
label

deekerman commented

2026-02-28 03:42:22 -05:00

Author

Owner

@CommanderStorm commented on GitHub (Dec 14, 2024):

If the username does not match exactly, you should not be allowed to log in.

That being said, the following seems like a good choice too.

being case agnostic for usernames
but not for passwords

@louislam what do you think:
Would the downgrade in security be acceptable?

@CommanderStorm commented on GitHub (Dec 14, 2024): If the username does not match exactly, you should not be allowed to log in. That being said, the following seems like a good choice too. - being case agnostic for usernames - but not for passwords @louislam what do you think: Would the downgrade in security be acceptable?

deekerman commented

2026-02-28 03:42:22 -05:00

Author

Owner

@homelab-alpha commented on GitHub (Dec 14, 2024):

@CommanderStorm, @louislam, Although it is not standard to make usernames case-sensitive, there are some arguments for situations where it might be necessary. Below are the arguments elaborated:

Uniqueness and Differentiation
- Argument: Case sensitivity allows for unique usernames, such as JohnDoe and johndoe as separate accounts. This can be useful in systems where usernames represent specific identities or contexts, such as technical platforms or databases.
- Example: A system where Admin and admin represent two different roles or permissions. Here, case sensitivity is a functional requirement.
Technical Consistency with Other Systems
- Argument: In certain environments (such as Unix/Linux systems), usernames are often case-sensitive. If an application integrates with such systems, it may be necessary to maintain the same sensitivity for usernames.
- Example: An organization using a single sign-on (SSO) solution where the backend requires case-sensitive usernames.
Additional Complexity Against Brute-Force Attacks
- Argument: While minimal, case sensitivity makes it harder for attackers to guess usernames because the number of possible combinations increases.
- Example: Instead of only guessing johndoe, attackers would need to try combinations such as JohnDoe, JOHNdoe, etc. This can slightly slow down brute-force attacks.
Consistency with Passwords
- Argument: Passwords are inherently case-sensitive for security reasons. Extending this logic to usernames can help maintain consistent security standards.
- Example: A system that enforces a uniform policy for all textual inputs supporting user authentication.
Specific Security Requirements
- Argument: Some organizations or systems have unique security requirements where case sensitivity might be necessary, such as niche applications or legal compliance.
- Example: A secure environment where usernames act as an additional identifier alongside passwords and certificates, with each letter’s case having significance.

Conclusion

While case sensitivity reduces user-friendliness, it can be useful or necessary in very specific cases. This is particularly true when technical or security objectives require username complexity, or when the system relies heavily on uniqueness and differentiation between usernames. However, in most standard environments, the drawbacks outweigh the benefits.

@homelab-alpha commented on GitHub (Dec 14, 2024): @CommanderStorm, @louislam, Although it is not standard to make usernames case-sensitive, there are some arguments for situations where it might be necessary. Below are the arguments elaborated: 1. **Uniqueness and Differentiation** - **Argument**: Case sensitivity allows for unique usernames, such as `JohnDoe` and `johndoe` as separate accounts. This can be useful in systems where usernames represent specific identities or contexts, such as technical platforms or databases. - **Example**: A system where `Admin` and `admin` represent two different roles or permissions. Here, case sensitivity is a functional requirement. 2. **Technical Consistency with Other Systems** - **Argument**: In certain environments (such as Unix/Linux systems), usernames are often case-sensitive. If an application integrates with such systems, it may be necessary to maintain the same sensitivity for usernames. - **Example**: An organization using a single sign-on (SSO) solution where the backend requires case-sensitive usernames. 3. **Additional Complexity Against Brute-Force Attacks** - **Argument**: While minimal, case sensitivity makes it harder for attackers to guess usernames because the number of possible combinations increases. - **Example**: Instead of only guessing `johndoe`, attackers would need to try combinations such as `JohnDoe`, `JOHNdoe`, etc. This can slightly slow down brute-force attacks. 4. **Consistency with Passwords** - **Argument**: Passwords are inherently case-sensitive for security reasons. Extending this logic to usernames can help maintain consistent security standards. - **Example**: A system that enforces a uniform policy for all textual inputs supporting user authentication. 5. **Specific Security Requirements** - **Argument**: Some organizations or systems have unique security requirements where case sensitivity might be necessary, such as niche applications or legal compliance. - **Example**: A secure environment where usernames act as an additional identifier alongside passwords and certificates, with each letter’s case having significance. ### Conclusion While case sensitivity reduces user-friendliness, it can be useful or necessary in very specific cases. This is particularly true when technical or security objectives require username complexity, or when the system relies heavily on uniqueness and differentiation between usernames. However, in most standard environments, the drawbacks outweigh the benefits.

deekerman commented

2026-02-28 03:42:22 -05:00

Author

Owner

@Ionys320 commented on GitHub (Dec 14, 2024):

Technical Consistency with Other Systems

That's the point, and in fact, the main issue for me. Some PRs prepare UK for external auth providers (LDAP for example with #4751). Therefore, we can't affirm all of the solutions have canse sensitive disabled.

For example, I just tried to connect to my LemonLDAP instance, binded to my LDAP. It appears my username is case-sensitive, and I can create another user with uppercases. Therefore, UK needs (at my point) to keep the username case-sensitive.

BUT something we can do is setting the username to lowercase on the registration/setup process, and when others users are created from UK (#3571), since lowercase is mainly used elsewhere.

@Ionys320 commented on GitHub (Dec 14, 2024): > Technical Consistency with Other Systems That's the point, and in fact, the main issue for me. Some PRs prepare UK for external auth providers (LDAP for example with #4751). Therefore, we can't affirm all of the solutions have canse sensitive disabled. For example, I just tried to connect to my LemonLDAP instance, binded to my LDAP. It appears my username is case-sensitive, and I can create another user with uppercases. Therefore, UK needs (at my point) to keep the username case-sensitive. BUT something we can do is setting the username to lowercase on the registration/setup process, and when others users are created from UK (#3571), since lowercase is mainly used elsewhere.

deekerman commented

2026-02-28 03:42:22 -05:00

Author

Owner

@homelab-alpha commented on GitHub (Dec 15, 2024):

@Ionys320, Although I stated in my conclusion, "However, in most standard environments, the drawbacks outweigh the benefits," I believe this does not apply to Uptime Kuma. Uptime Kuma uses 2FA (Two-Factor Authentication), and it is considered best practice for usernames to be case-sensitive for 2FA implementations in general.

As a personal note, I support some user inconvenience if it leads to better security. I hope that @louislam agrees with this approach and keeps the username case-sensitive.

@homelab-alpha commented on GitHub (Dec 15, 2024): @Ionys320, Although I stated in my conclusion, "However, in most standard environments, the drawbacks outweigh the benefits," I believe this does not apply to Uptime Kuma. Uptime Kuma uses `2FA` (Two-Factor Authentication), and it is considered best practice for usernames to be case-sensitive for `2FA` implementations in general. As a personal note, I support some user inconvenience if it leads to better security. I hope that @louislam agrees with this approach and keeps the username case-sensitive.

deekerman commented

2026-02-28 03:42:22 -05:00

Author

Owner

@louislam commented on GitHub (Dec 15, 2024):

Yes, I think we should keep the current implementation, simply because I don't want to create any unexpected breaking change, for example, if someone has already created Admin and admin in the SQLite database, it might run into problems.

But I remember there were some people said that, their saved passwords were not working, it may be because of this.

@louislam commented on GitHub (Dec 15, 2024): Yes, I think we should keep the current implementation, simply because I don't want to create any unexpected breaking change, for example, if someone has already created `Admin` and `admin` in the SQLite database, it might run into problems. But I remember there were some people said that, their saved passwords were not working, it may be because of this.

deekerman commented

2026-02-28 03:42:22 -05:00

Author

Owner

@homelab-alpha commented on GitHub (Dec 15, 2024):

But I remember some people said that their saved passwords weren't working, and it might be because of this.

@louislam, Can you provide more context about this? So far, from what I've seen and understood, the passwords are not stored as plaintext but hashed? Or am I mistaken?

@homelab-alpha commented on GitHub (Dec 15, 2024): > But I remember some people said that their saved passwords weren't working, and it might be because of this. @louislam, Can you provide more context about this? So far, from what I've seen and understood, the passwords are not stored as plaintext but hashed? Or am I mistaken?

deekerman commented

2026-02-28 03:42:22 -05:00

Author

Owner

@Ionys320 commented on GitHub (Dec 15, 2024):

I guess the main issue is password manager can set the username to lowercase. That's why I suggested this:

something we can do is setting the username to lowercase on the registration/setup process, and when others users are created from UK (https://github.com/louislam/uptime-kuma/pull/3571), since lowercase is mainly used elsewhere.

@Ionys320 commented on GitHub (Dec 15, 2024): I guess the main issue is password manager can set the username to lowercase. That's why I suggested this: > something we can do is setting the username to lowercase on the registration/setup process, and when others users are created from UK (https://github.com/louislam/uptime-kuma/pull/3571), since lowercase is mainly used elsewhere.

deekerman commented

2026-02-28 03:42:22 -05:00

Author

Owner

@homelab-alpha commented on GitHub (Dec 15, 2024):

@Ionys320, I don't know of any password manager that defaults to converting usernames to lowercase. If this happens, it seems to be a user error in the settings of the password manager.

If this is not the case, I recommend switching to another password manager, such as Bitwarden.

@homelab-alpha commented on GitHub (Dec 15, 2024): @Ionys320, I don't know of any password manager that defaults to converting usernames to lowercase. If this happens, it seems to be a user error in the settings of the password manager. If this is not the case, I recommend switching to another password manager, such as Bitwarden.