insecure plain-text mysql password in odb
Issue #333
new
ODB /Logger/SQL/Password contains a plain text mysql password. Anybody with access to an odb dump, an odb save file, midas web page or midas raw data file (with an odb dump inside) can use it to connect to this database. if mysql server only accepts connections from localhost, problem is restricted to local users. if mysql server accepts connections from the world, this is a security problem. (if this plain text password is reused elsewhere, it is an even bigger security problem). one solution is to store this password in a file that is not trivially accessible on the web through mhttpd. K.O.
Comments (7)
-
-
reporter
it is a bad security practice to use plain-text passwords. login using ssh keys, tokens, etc. (this is more of a problem with mysql authentication)
it is a bad security practice to publish plain text passwords on github (embedded in source code), and in every raw data file produced by an experiment (embedded in ODB dumps).
-
I agree. But what can we do? mysql authentication requires a plain password. The only “clean” solution I see is to configure mysql to require NO password, but restrict the access for that account to the DAQ machine.
-
reporter
for the MySQL history, I store the MySQL password in a text file, not in ODB. K.O.
-
I tried that as well, but then some person put that file under git, and it ended up in github or bitbucket. A plain password file in a plain text file is not more secure that the same in an ODB dump file. What we really need would be some more advanced mysql authentification.
-
reporter
two different situations. (1) a person makes a misguided decision to publish plain-text password in a world-readable location, (2) midas software by design publishes plain-text password in a world-readable location. Fix for (1) is to change the password. This fix is ineffective for (2) as midas will publish the new password in the same world-readable location. K.O.
-
Just to make this clear: I’m not against putting a password in a file, I’m only not convinced that this is the ultimate solution. If you want to implement it, you should do it in a way which does not break existing installations which use passwords in the ODB. So like putting a “@” as the first character tells the system to load the password from the file after the “@”, like “@passwd.txt”. If the “@” is missing, use the string directly as password.
- Log in to comment
Indeed it felt strange when I first put the password in the ODB some ~ten years ago, but in meantime I’m more relaxed. First, what would happen if some hacker connects to your database. Will he steal history data? Or manipulate your metadata such that you think you discovered a new particle? If someone really wants to hurt an experiment, he can do a DDOS attach on the DAQ machine and bring down the experiment for some time.
Second, putting the password in a file won’t do much help. At PSI, shared passwords are forbidden, so everybody accesses DAQ with his/her PSI credentials. But all people who have PSI credentials can also log in to the DAQ machine and read the password file. Sure one can make this root read only, but then you have to start mhttpd as root, another security problem.
Am I missing anything?