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

[GeyserLaPunk]

• 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

[zeripath]

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

[GeyserLaPunk]

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.

[lunny]

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

[GeyserLaPunk]

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.

[zeripath]

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.

[GeyserLaPunk]

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.