Hello.
I currently have an application deployed and running and just recently I have been asked to encrypt the database password. The password is in the database.yml file.
What would be the easiest way of making this work?
Thank you.
Pepe
If they're asking you to encrypt the password in the database.yml file itself, you kinda can't. I think the best you can do is secure the flle's read permissions so that it can only be read by the owner (which should be the process that runs the app.)
If they can get access to that file and read its contents, chances are good that they can also start up the console, modify your ruby code, and change your app. The DB password in that file is the least of your problems.
I realize that might not be the best answer, but as I understand it, it's not possible to do db password encryption out of the box.
Anyone else know a better solution?
Thanks Brian
Like you said, it's not the best answer in this case. The company policy has changed and these people are scrutinized by the government, so the encryption is pretty much a must do.
I have two ideas to solve this:
1. Hack the 'establish_connection' method (wherever it is. I am not an expert...) and before the method is used decrypt the password already read from database.yml. 2. Create a class that would establish the connection from within the models I have themselves and forget about going the regular Rails way.
I don't like either way and I was just hoping that somebody had already ran into this and had a better solution.
Thanks for your suggestion, though.
Pepe
policy has changed and these people are scrutinized by the government, so the encryption is pretty much a must do.
Reality and "must do" sometimes conflict 
1. Hack the 'establish_connection' method (wherever it is. I am not an expert...) and before the method is used decrypt the password already read from database.yml.
If you have a way to "decrypt the password" in the code, then anyone with access to the system can find it, and get the password, or use the routine to execute their own code. No different than reading it out of database.yml.
2. Create a class that would establish the connection from within the models I have themselves and forget about going the regular Rails way.
See above.
I don't like either way and I was just hoping that somebody had already ran into this and had a better solution.
The only way around it is to have someone enter the password into the system at startup, which means no automatic restart. If you've got 24x7 admin support, that may be acceptable. But even that's not a perfect solution if your system's been compromised.
Better to keep the bad guys out of your system in the first place, I'd
think
FWIW,
also, don't run with the root account. Set up a special user for the rails app to use, and set permission appropriately. That way, if someone manages to get onto your server and get the db password, they only have access to a smaller part of the db.
Simon
The key is to work out what you actually want to achieve.
If you're worried about someone stealing your laptop and accessing your local copy of the database, then;
- store you mysql data files on an encrypted partition. - if someone can get onto your machine, they'll also have to know the password to decrypt that partition, and hence access the database
If you're worried about someone getting onto your production server, logging onto your database, and then stealing your data, then;
- only allow access to your servers from trusted IPs (probably just your office) - ensure that root access via SSH is disabled - only allow access to servers via ssh-keys, and only use keys which have a password encoded - ensure that mysql is only accessible from your production servers - ensure that your production servers are up-to-date and kept up-to- date with the latest security patches.
As an minor additional point, don't check in your database.yml
use a separate one that is copied in when you deploy to your production servers. thereby removing any hints as to what your db usernames and password might be, until you've already hacked into your super-secure servers.
Pepe,
Unless you have a secure dedicated HW (something along the lines of the HSMs used in the financial industry), just encrypting the password is no better, as the encryption key must be stored somewhere and you end up with exactly the same problem...
Cheers, Sazima
Funny this would end up on a discussion on Rails.
We have clients on other products asking to encrypt the passwords and encrypt this and that (funny also they are gov. bodies too).
The explanation about securing the server and restricting access to the file did not resolve the question.
What did resolve the question was:
- encryption the information with the private portion of a PPK (public/ private key). - use a smartcard installed on the server with the public portion of the PPK
This approach does not resolve physical access to the computer but it does limit the accessibility to the data. It does not resolve the following:
1. the party takes control of the machine where the smartcard is connected (if you can control the machine it is very likely you can access the information on the smartcard). 2. your facility is invaded and the smartcard is stolen.
Hello to all. Sorry to have answered this late, I've been out for Thanksgiving.
Wow! I didn't know I knew so little about securing servers. Thanks
so much to all of you for all your answers.
I have to agree. I have always thought that keeping the bad guys out
should be done by the people that are best supposed to know about it,
the network and security guys. I am just a lowly coder.
My guess is that the thought behind the password encryption request is really to try and make life a bit more difficult to the less skilled inside hackers (read here their own employees). Not long ago I was told by a security expert that over 90% of hack attacks are insider jobs.
I'll pass along a link to this discussion to the person in charge. I hope they realize that the password encryption is not the solution to the problems they're trying to prevent.
Many thanks to all of you.
Pepe
