Description:
Hello folks,
Here's a feature request I hope you find reasonable: the User_password column is plain text right now:
master [localhost:22233] {msandbox} (mysql) > select * from slave_master_info\G
*************************** 1. row ***************************
Number_of_lines: 33
Master_log_name: tp-support03-bin.000004
Master_log_pos: 154
Host: 127.0.0.1
User_name: root
User_password: msandbox
...
This is frown upon by many security auditors, so the feature request is having this hashed as it is in mysql.user.authentication_string (or in any other non-plain-text format).
The example above is a simple async replication, but a good example of how this can happen is if you use MySQL Shell to setup a GR group from a existing standalone instance, you will end up with entries like:
*************************** 2. row ***************************
Number_of_lines: 33
Master_log_name:
Master_log_pos: 4
Host:
User_name: mysql_innodb_cluster_100
User_password: Y,[?}*H|1.d#U#}|%y>4(}k_$*[x2{L~
Port: 3306
Connect_retry: 60
Enabled_ssl: 0
Ssl_ca:
Ssl_capath:
Ssl_cert:
Ssl_cipher:
Ssl_key:
Ssl_verify_server_cert: 0
Heartbeat: 0
Bind:
Ignored_server_ids: 0
Uuid:
Retry_count: 86400
Ssl_crl:
Ssl_crlpath:
Enabled_auto_position: 1
Channel_name: group_replication_recovery
How to repeat:
Use MySQL shell to create a cluster:
mysqlsh> dba.createCluster('gr1');
Then check contents of mysql.slave_master_info and verify passwords are being shown in plain text for automagically created user.
Suggested fix:
Don't store the password in plain text anywhere
Description: Hello folks, Here's a feature request I hope you find reasonable: the User_password column is plain text right now: master [localhost:22233] {msandbox} (mysql) > select * from slave_master_info\G *************************** 1. row *************************** Number_of_lines: 33 Master_log_name: tp-support03-bin.000004 Master_log_pos: 154 Host: 127.0.0.1 User_name: root User_password: msandbox ... This is frown upon by many security auditors, so the feature request is having this hashed as it is in mysql.user.authentication_string (or in any other non-plain-text format). The example above is a simple async replication, but a good example of how this can happen is if you use MySQL Shell to setup a GR group from a existing standalone instance, you will end up with entries like: *************************** 2. row *************************** Number_of_lines: 33 Master_log_name: Master_log_pos: 4 Host: User_name: mysql_innodb_cluster_100 User_password: Y,[?}*H|1.d#U#}|%y>4(}k_$*[x2{L~ Port: 3306 Connect_retry: 60 Enabled_ssl: 0 Ssl_ca: Ssl_capath: Ssl_cert: Ssl_cipher: Ssl_key: Ssl_verify_server_cert: 0 Heartbeat: 0 Bind: Ignored_server_ids: 0 Uuid: Retry_count: 86400 Ssl_crl: Ssl_crlpath: Enabled_auto_position: 1 Channel_name: group_replication_recovery How to repeat: Use MySQL shell to create a cluster: mysqlsh> dba.createCluster('gr1'); Then check contents of mysql.slave_master_info and verify passwords are being shown in plain text for automagically created user. Suggested fix: Don't store the password in plain text anywhere