Passwords in configuration files

[DAveShillito]

Hi,

This is a general Linux question, but TBH I have generally found these forums are one of the most helpful places online, so hope no one will mind me asking this here.

I've been looking at a tutorial explaining how to back up my Owncloud installation on one of my Pi's (http://www.dudemydadsageek.com/2014/02/ ... tallation/)

This instructs me to add the following to a configuration file

Code: Select all

# backup Owncloud database and make readable only by root
/usr/bin/mysqldump -uowncloud -ppassword owncloud > owncloud_db.sql 
/bin/chmod 600 owncloud_db.sql

In common with a number of Linux tutorials I have found, usernames and passwords are placed in plain text in script and configuration files. This however goes against my years of accrued wisdom that you don't write passwords down.

Is this just the 'Linux way' and we rely on the fact that those files are owned by root, so can only be read by someone who has the root password... or am I missing something?

Cheers,

DAve

[bobstro]

The mysql documentation discusses the issue at length and details other options that can be used. It's always worth researching what any online article is telling you to do, much less accept a site called "Dude My Dad's a Geek" as authoritative.

[DAveShillito]

It's always worth researching what any online article is telling you to do, much less accept a site called "Dude My Dad's a Geek" as authoritative.

Exactly, that's why I asked the question here before continuing

I have a distinct dislike for instructions that tell you "just do this" and will try to hunt down alternative sites which explain what "this" is. This does unfortunately often mean I have to piece together multiple similar, but slightly different, approaches, but... hey... that's what learning is all about .

That said, this approach to passwords is one I have seen outlined on many sites, probably as a result of one person being told "do it this way" and passing that on to someone else... who passes it on... etc.

Thanks for that link I shall go and investigate

DAve

[DougieLawson]

It's a "Linux way" to hide passwords in files that can only be read by root. In general that's an exceedingly bad idea. The main thing with Raspbian on the RPi is that the use of root is much more open than on a regular system because of the need to be root to wiggle the GPIO pins from python using RPi.GPIO. You can harden the system, starting with an update to the /etc/sudoers file.

The underlying problem is that your SQL data includes plain text passwords rather than encrypted passwords. That's a problem for the Owncloud developers to resolve.

The stuff on dudemydadsageek seems to be sane and a reasonable list of stuff to do to get a safe and consistent backup.

[solar3000]

there's a way to encrypt it and then paste it in your plain text file.


start here:
http://www.vidarholen.net/contents/blog/?p=32

then do some more google-fu.

[jojopi]

In common with a number of Linux tutorials I have found, usernames and passwords are placed in plain text in script and configuration files. This however goes against my years of accrued wisdom that you don't write passwords down.

What is the alternative? Either someone types the password every time, or it has to be stored and readable. You cannot encrypt it, because then you have the same problem with storing the encryption key. (There is the concept of using an agent, which holds the encryption key in RAM, so that it only needs to be typed once per boot. I have not heard of that being done for something as unimportant as a DB password.)

The key thing to realise is that passwords are dead technology. If your database only accepts connections from localhost, then the password does not authorize anything that a privileged user could not do directly with the table files in /var/lib/mysql (or by reading blocks directly from the SD card). If your database accepts network connections, then the password alone is unlikely to provide sufficient security. You want to restrict access by IP as well.

If you were connecting to the database from outside of your trusted VLAN, then you should probably do so via an SSH or VPN tunnel using strong encryption and authentication, rather than open mysql's password mechanism to the internet.

As for the mysqldump script, it is best to avoid the -ppassword command line argument, because other users may be able to read it in the output of "ps". See bobstro's link. Also it is really too late to chmod the output file after the dump has finished. Anyone can open it for reading in the meantime. Both of these are only really a concern if you have untrusted users on the same machine.

I am not sure I would want the backups only to be readable by root. The database admins are not necessarily the same people as the operating system admins.

[davidcoton]

In common with a number of Linux tutorials I have found, usernames and passwords are placed in plain text in script and configuration files. This however goes against my years of accrued wisdom that you don't write passwords down.

What is the alternative?

At a very basic level, the password is stored in an encrypted form with the key part of the program code. Far from unhackable, but much better than having plain text passwords stored.

[jojopi]

At a very basic level, the password is stored in an encrypted form with the key part of the program code. Far from unhackable, but much better than having plain text passwords stored.

It is hard to see how that could be applied to this thread. You want to compile the password for the owncloud database into the binary of mysqldump?

Again, this password is discretionary. A privileged user can already change it at will, or access the database tables without it. The important thing is not to trust remote users just because they know the password.

Even outside of this thread, I do not see how storing credentials with a reversible encryption is better than storing them plaintext. You seem to be hoping your attacker cannot use a debugger, instead of simply restricting read access to authorized personnel.

[davidcoton]

You want to compile the password for the owncloud database into the binary of mysqldump?

No, I want the encryption algorithm and key in the binary. The password (in its encrypted form) can then be in a text file. Actually I don't want it, I just answered the question about how it could be. I guess it is a case where a database is now being used in ways the designers never expected, so this part of their security model is broken. And as I said, its not very secure. Just good enough, as used to be said about defence equipment factory restricted access, to keep honest people honest. The assumption was, if you were found where you shouldn't be, you were not there by accident. Unfortunately cyber intruders are less likely to be caught.

[jojopi]

No, I want the encryption algorithm and key in the binary. The password (in its encrypted form) can then be in a text file.

So if I can read the text file I can access the database, and nothing has really changed?

If program A has to give program B a password, then there is just no way to automate that that does not amount to writing the password down. Reusable passwords are dead.

It is not a problem in this case, because even if I know the password, hopefully it only works from localhost. If any remote access to the database is allowed, it can use a different password, have privilege over fewer tables, or additional layers of security.

[davidcoton]

So if I can read the text file I can access the database, and nothing has really changed?

The password (in its encrypted form) can then be in a text file.

You can read the encrypted form. By making multiple attempts to set passwords you can crack the algorithm, and if it is reversible, you can decode it. But the encrypted password will not give you immediate access to the database. It all depends how much security you want or need.

[jojopi]

You can read the encrypted form. By making multiple attempts to set passwords you can crack the algorithm, and if it is reversible, you can decode it. But the encrypted password will not give you immediate access to the database. It all depends how much security you want or need.

The purpose of storing a password in this thread is to perform unattended database dumps on a regular basis. Your "encrypted" password must allow immediate read access to all tables, just like the original did.

[davidcoton]

The purpose of storing a password in this thread is to perform unattended database dumps on a regular basis. Your "encrypted" password must allow immediate read access to all tables, just like the original did.

Well, that's OK with a reversible algorithm. Which is probably sufficient if you are happy to let an unattended program get through password security anyway.

[DAveShillito]

Thanks everyone for the discussion.

From reading the SQL docs bobstro linked to it looks to me that there are the following options

1. Use -ppassword as in the example - but this exposes the command line to ps
2. Store the password in an option file, that will live in /root - so it is effectively the "Linux way" I first mentioned, but not available to ps
3. Store the password in the MYSQL_PWD environment variable, which generally just sounds bad
4. Do not run this as an automatic process, but do it manually.

I think option 2 looks like the one I will go with.

I'm not sure how encrypting the password would help (if sqldump even allows encrypted passwords) since as jojopi said...

So if I can read the text file I can access the database, and nothing has really changed?

And the intention here is to allow unattended regular backups, so I would need to put the encrypted password in the script.

Also

The underlying problem is that your SQL data includes plain text passwords rather than encrypted passwords. That's a problem for the Owncloud developers to resolve.

I'm not sure this is true, as the problem I'm trying to resolve is how the backup the mysql database.
Yes it may be true that Owncloud user passwords are not encrypted, and that would be a problem for the Owncloud dev,'s ro resolve but I just need to worry about backing up the database and keeping it safe once I have.

As to general security, I have my own personal account on the pi, have removed the pi use and only allow encrypted ssh access. There is a firewall in place, however I decided not to restrict access to only a few external IP addresses since I want to be able to access anywhere.

I'm sure there is more I can, do, but as usual its about balancing security with ease of use.

Once again, thanks for the assistance

DAve

[bobstro]

[...]
[*]Store the password in an option file, that will live in /root - so it is effectively the "Linux way" I first mentioned, but not available to ps

You seem to be moving the goalpost on what the "Linux way" is. You've now got the option to put it in the root user's directory with permissions restricting access to the root user. That's a world of difference from storing it in a configuration file under /etc with any user able to access it.

The characterization as the "Linux way" is incorrect. If you're truly worried about someone gaining access to the root user account, the "Linux way" provides a number of other protections you can choose to use if you're truly concerned, including encrypted filesystems, VPNs and so forth. You certainly wouldn't want your security to stand or fall based on a single layer of protection, would you?

[...] I'm sure there is more I can, do, but as usual its about balancing security with ease of use

Tools are provided to do as much or as little as you want, and no one tool is expected to do everything. Presumably, you've realized that every potential exposure does not automatically equate to risk, and made the appropriate decisions to mitigate risk to acceptable levels. That is the "Linux way".