Security issue: do not store LDAP passwords in MySQL database

[PunisherHD92]

Current status: when using LDAP authentication for Loganalyzer users, the password is stored in loganalyzer database is stored using md5 hash.
Firstly, the md5 hash is weak and can be bruteforced.
Secondly, the LDAP password should NOT be store in the database anyway.
This PR prevents loganalyzer storing the LDAP password in Mysql database.

[gemini-code-assist]

Summary of Changes

Hello @PunisherHD92, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request implements a critical security enhancement by stopping the practice of storing LDAP user passwords directly within the LogAnalyzer database. Previously, these passwords were hashed using MD5, which is considered a weak algorithm, and storing them at all for LDAP users is an unnecessary security risk. The change ensures that only necessary user information, excluding the LDAP password, is retained in the database.

Highlights

• Security Fix: Addresses a security vulnerability where LDAP user passwords were being stored in the LogAnalyzer database using a weak MD5 hash.
• Password Storage Prevention: Modifies the CheckLDAPUserLogin function to prevent the storage of LDAP passwords in the MySQL database by setting the $md5pass variable to an empty string.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request addresses a security vulnerability by preventing LDAP user passwords from being stored in the database. The change correctly replaces the password hashing logic with an empty string for the password field when an LDAP user is created in the local database. This effectively prevents the password from being stored. My review includes a suggestion to use a more conventional method for disabling password-based logins, which enhances clarity and robustness. Overall, this is a valuable security improvement.

[gemini-code-assist]

While setting the password to an empty string works, a more robust and conventional approach to disable password-based login for an account is to set the password hash to an invalid value that cannot be generated by the hashing algorithm. A common convention, for example in /etc/shadow files, is to use a single asterisk (*). This makes it clearer that password login is intentionally disabled and prevents any potential edge cases with empty strings.

	/* Don't store LDAP passwords in database, and disable login with local password */
	$md5pass = '*';

[alorbach]

/gemini review

[gemini-code-assist]

Code Review

This pull request updates the LDAP user login function to stop storing user passwords in the database by setting the password variable to an empty string. The review suggests extending this security improvement to clear existing password hashes for users already in the database and recommends renaming the $md5pass variable to a more descriptive name to reflect its current usage.

[gemini-code-assist]

This change correctly prevents storing passwords for new LDAP users. However, to fully satisfy the security objective of not storing LDAP passwords in the database, existing users who have previously logged in will still have their MD5 hashes stored in the password column. Consider adding logic to clear the password field for existing users after they are successfully authenticated and fetched from the database (around line 397).

Additionally, the variable name $md5pass is now misleading as it no longer contains an MD5 hash; consider renaming it to something more generic like $storedPassword in a future refactoring.