Passwords for Database user and LDAP bind user are stored in plain text #7175

New Issue

GiteaMirror · 2025-11-02T07:18:30-06:00

GiteaMirror commented

2025-11-02 07:18:30 -06:00

Originally created by @GeyserLaPunk on GitHub (Apr 13, 2021).

Gitea version (or commit ref): 1.13.7
Git version: 2.14.0
Operating system: Windows 10/Server 2012
Database (use [x]):
- PostgreSQL
- MySQL
- MSSQL
- SQLite
Can you reproduce the bug at https://try.gitea.io:
- Yes (provide example URL)
- No
Log gist:

Bad security practice of storing passwords in plain text

Description

While application does provide a warning that it stores password in plain text, I think we all agree that this is a big security issue independently from how many privileges user has.
There is an existing module modules/secret/secret.go that allows for two way encryption. Why is it not used to encrypt password values stored in app.ini and in the database in case of LDAP auth.
...

Screenshots

Originally created by @GeyserLaPunk on GitHub (Apr 13, 2021).   - Gitea version (or commit ref): 1.13.7 - Git version: 2.14.0 - Operating system: Windows 10/Server 2012    - Database (use `[x]`): - [ ] PostgreSQL - [ ] MySQL - [x] MSSQL - [ ] SQLite - Can you reproduce the bug at https://try.gitea.io: - [ ] Yes (provide example URL) - [ ] No - Log gist:    Bad security practice of storing passwords in plain text ## Description  While application does provide a warning that it stores password in plain text, I think we all agree that this is a big security issue independently from how many privileges user has. There is an existing module modules/secret/secret.go that allows for two way encryption. Why is it not used to encrypt password values stored in app.ini and in the database in case of LDAP auth. ... ## Screenshots

GiteaMirror added the topic/security label 2025-11-02 07:18:30 -06:00

GiteaMirror closed this issue

2025-11-02 07:18:31 -06:00

GiteaMirror commented

2025-11-02 07:18:32 -06:00

@zeripath commented on GitHub (Apr 13, 2021):

It sounds like you have identified the issue and the solution. Perhaps you could provide a PR?

@zeripath commented on GitHub (Apr 13, 2021): It sounds like you have identified the issue and the solution. Perhaps you could provide a PR?

GiteaMirror commented

2025-11-02 07:18:32 -06:00

@GeyserLaPunk commented on GitHub (Apr 14, 2021):

It sounds like you have identified the issue and the solution. Perhaps you could provide a PR?

While I would like to help as much as I can, however I never wrote a line of code in GO, so until I'm comfortable doing it I should pass this opportunity to someone with more experience.

The logic should be pretty simple: you encrypt it as soon as you read it and decrypt it only when you need to use it.

@GeyserLaPunk commented on GitHub (Apr 14, 2021): > It sounds like you have identified the issue and the solution. Perhaps you could provide a PR? While I would like to help as much as I can, however I never wrote a line of code in GO, so until I'm comfortable doing it I should pass this opportunity to someone with more experience. The logic should be pretty simple: you encrypt it as soon as you read it and decrypt it only when you need to use it.

GiteaMirror commented

2025-11-02 07:18:32 -06:00

@lunny commented on GitHub (Apr 14, 2021):

I cannot know what do you mean. Which table and which column?

@lunny commented on GitHub (Apr 14, 2021): I cannot know what do you mean. Which table and which column?

GiteaMirror commented

2025-11-02 07:18:32 -06:00

@GeyserLaPunk commented on GitHub (Apr 14, 2021):

I cannot know what do you mean. Which table and which column?

Table: login_source,
Column: cfg

When login source is LDAP via BindDN bind password value within JSON string is plain text.
Not sure if any other sources have similar issue as I haven't tried them.

Also, database user password in app.ini database section PASSWD value is plain text as well.

@GeyserLaPunk commented on GitHub (Apr 14, 2021): > I cannot know what do you mean. Which table and which column? Table: login_source, Column: cfg When login source is LDAP via BindDN bind password value within JSON string is plain text. Not sure if any other sources have similar issue as I haven't tried them. Also, database user password in app.ini database section PASSWD value is plain text as well.

GiteaMirror commented

2025-11-02 07:18:32 -06:00

@zeripath commented on GitHub (Apr 19, 2021):

That the configuration file contains necessary passwords for configuring the service is essentially unfixable - at some point these have to be unencrypted and the secrets have to become available some way.

I have however, put a PR up that encrypts the ldap bind password within the db.

@zeripath commented on GitHub (Apr 19, 2021): That the configuration file contains necessary passwords for configuring the service is essentially unfixable - at some point these have to be unencrypted and the secrets have to become available some way. I have however, put a PR up that encrypts the ldap bind password within the db.

GiteaMirror commented

2025-11-02 07:18:32 -06:00

@GeyserLaPunk commented on GitHub (Apr 20, 2021):

That the configuration file contains necessary passwords for configuring the service is essentially unfixable - at some point these have to be unencrypted and the secrets have to become available some way.

I would have to respectfully disagree with your statement. Any password should be encrypted the moment it was read during initial setup and held in the encrypted state in any long term storage (memory, text file, etc.). decryption should occur at the place of the immediate use, such as when connection to DB is happening. It just feels like a common sense.

I have however, put a PR up that encrypts the ldap bind password within the db.

That is a step in the right direction. Thank you.

@GeyserLaPunk commented on GitHub (Apr 20, 2021): > That the configuration file contains necessary passwords for configuring the service is essentially unfixable - at some point these have to be unencrypted and the secrets have to become available some way. I would have to respectfully disagree with your statement. Any password should be encrypted the moment it was read during initial setup and held in the encrypted state in any long term storage (memory, text file, etc.). decryption should occur at the place of the immediate use, such as when connection to DB is happening. It just feels like a common sense. > I have however, put a PR up that encrypts the ldap bind password within the db. That is a step in the right direction. Thank you.

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/gitea#7175