Feature Request: Encrypting password of Monitor user

[tbustik]

Hello,

would you please consider adding following feature to ProxySQL?
The ability to store the password of monitor user in an encrypted form (e.g. sha1(plaintext)) instead of plain text in the global_variables table.
Storing any password in a plain text form is considered a security bug in our company's policy.

Thank you

[llchan]

Another option that may be more flexible is a user-supplied executable that can be run to retrieve monitor credentials. This allows the user to fetch secrets from their preferred secrets store without having to support each one explicitly in proxysql. In that scenario, we wouldnt store it on disk at all, and it would only sit in memory.

[bparli]

I'd expand this request to any passwords or credentials in the global_variables table. admin_credentials in particular

[dwoo2dwoo]

I'd expand this request to any passwords or credentials in the global_variables table. admin_credentials in particular

You can already do this; e.g.:
admin_credentials="admin:*F84B0B3D3AC915064C4A6334579AF185E3EF1301"

[jdanilson]

Where is the documentation for support of storing encrypted password(s) in the global_variables table for admin-credentials? Does this work for other admin credentials stored in this column?
Does this also apply to the other stored passwords and credentials in this table for monitor user, cluster user, and read-only admin user(s)?

The documentation here:
https://proxysql.com/documentation/global-variables/#admin-admin_credentials
makes no mention of an ability to encrypt this column.

[tbustik]

@jdanilson Is this what you are looking for?
https://github.com/sysown/proxysql/wiki/Password-management#password-formats

[jdanilson]

No. The ability to store the hash for users in the mysql_user table has existsed for a while and we use it

My question deals with user passwords stored in the global_variables table (and by reference most are also coded in the cnf file). There is information about hashing the admin_admin_password but not the monitor and cluster users. I wish there was just a simple way to accomplish this, especially since the easy to use password() function is going away in mysql 8.x

[c609942867]

Any update on this requirement？

[worstkid92]

any updates on this issue? we are also looking for a solution.

[worstkid92]

@jdanilson do you have any updates on this issue?

[worstkid92]

Hello,

would you please consider adding following feature to ProxySQL? The ability to store the password of monitor user in an encrypted form (e.g. sha1(plaintext)) instead of plain text in the global_variables table. Storing any password in a plain text form is considered a security bug in our company's policy.

Thank you

do you have any updates on this solution? my company has similar policy.

[renecannao]

There are a lot of people in this thread, so I think I can get some feedback.

First of all, let me explain some details about passwords.
Because ProxySQL it is a server during the client-server authentication phase when a client connects, it can store passwords hashed (sha1(sha1(plaintext)) , double sha1) and when a client connects it can verify that the client has a valid password.

When ProxySQL connects to a backend instead it is a client.
ProxySQL cannot initialize any backend connection if it doesn't have the password, either in clear text or in the form of a sha1(plaintext) when using mysql native authentication.
Currently proxysql can derive sha1(plaintext) during the client handshake, thus it can store it in memory to then connect to the backend.

Based on the above:

• proxysql can store the password in sha1(sha1(plaintext)) only for user that connects TO proxysql
• for connections from proxysql TO backend, either plaintext or sha1(plaintext) is needed
• we cannot store Monitor's password as sha1(sha1(plaintext)) , because it will be unusable
• from a security point of view, storing sha1(plaintext) is not safer then storing plaintext : it can still be used to connect to the backend . I don't see why a security policy would consider sha1(plaintext) ok. Unless the security policy is just about plain text and not really about security.

Question: how do you store passwords in the application?

[worstkid92]

thanks for your reply.
it seems if we use proxysql,it cannot be avoided to use palintext or sha1.
In our company we have our unique password encryption algorithm.
Anyway thanks a lot.

[jdanilson]

Rene.
Thanks for your explanation but unfortunately the storing of any password in cleartext is not allowed; government rules. We have continued to get a waiver from our cyber team but eventually that will expire.

To answer your question about how applications authenticate. We begin with a mysql password which is given to the app operations team. They change this password; we do not then have the password. They encrypt the new password and store the encrypted value in the applications configuration file. The application calls a supplied api with a key and the encrypted password which returns the unencrypted password and proceed to login to mysql. The key is unique to the application and is stored securely but I do not know those details. All of this communications uses ssl. Passwords are changed every 90 days.

I recognize your issue with these "client" passwords and suggest it might be a workaround to use an agreed upon encryption method. I totally understand such a solution is security theatre and not necessarily a good solution but it would allow us to answer cyber that the password is encrypted thereby meeting their requirement. Once we answer in the affirmative Cyber typically does not dive into the details.

[alip7676]

Hi friends,

any update on this particular issue ?
apparently my company policy seen this as security bug, hopefully there's way out to solve this. any workaround i really appreciate.

thanks

[thiborgesnvs]

Look at this PR --- > #4258