Company's compliance don't allow the Blind Password stored as plain text

Install/Maintain/Configure
1

The Bind Password in Authentication Sources is stored as plain text in the gitea.db file. We use SQLite as the database. Due to company’s compliance requirement, the Blind Password cannot be stored as plain text. Could you please provide a way for this problem?

image
image1593×792 49.5 KB

2

Hmmm, I’m not sure on a way around this. Since the password wouldn’t be typed each time, there’s no way to validate it against a hashed password.

The only other thing I can think of is to allow it to look up a config or env variable.
Admittedly I’m not a security expert, so there is certainly a chance I’m missing something obvious.

3

Perhaps we should do a symmetric encryption with a value stored in app.ini or coming from an ENV variable. This is only obfuscation, because one value can be derived from the other anyway, but at least it will not show up in a database backup.

But this would render an installation unrecoverable if such password is lost, so it should only be used strictly when required.

4

Jolheiser, thanks for the reply!

I am trying to add some simple encryption to the bindpassword so that it will not be seen directly by editing the db file. I have 2 approaches to the solution.

  1. Encrypt the password as soon as it is read from the web page. Decrypt the bindpassword as it is used to read the AD data. For this approach, the difficult is to find the place when the bindpassword is read from the web page.

  2. Encrypt the password as it is written to the database. Decrypt the password as it is read from the database. I am searching for the SQL statement of ‘INSERT INTO’ and ‘UPDATE’ for encryption. But I found that the bindpassword is not written directly into the database but the authentication source data is written as a whole.

Approach 1 seem to be easier but can you let me know where can I put the encryption code when the bindpassword is read?

5

It seems this would require some code changes on your end.

auths.go is where the LDAP config is parsed backend. And login_source.go is where the config struct is.

You would need to encrypt the password as it gets parsed, and then decrypt it as it comes out of the DB.

Please keep in mind that this is security through obscurity and should not be relied upon as a true security measure.
If anyone gets hold of the DB, you should treat this password as lost regardless of this change.