Database password encryption


#1

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


#2

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?


#3

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


#4

On Thu, 27 Nov 2008 13:51:45 +0900, Hassan S.
removed_email_address@domain.invalid wrote:

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


#5

On Nov 26, 10:07 pm, pepe removed_email_address@domain.invalid wrote:

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.

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.


#6

On Wed, Nov 26, 2008 at 8:08 PM, pepe removed_email_address@domain.invalid wrote:

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 :slight_smile:

  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.

  1. 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 :slight_smile:

FWIW,

Hassan S. ------------------------ removed_email_address@domain.invalid


#7

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


#8

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.

Personally I think there is way too much attention given to encryption
as a mean to secure stored information… you always need to provide a
mean to retrieve it which makes it insecure if that mean is
compromised.

My personal preference on that level is to:

  1. ensure is visible only to users who should see it (can be done with
    file/network security… no need for encryption there).
  2. ensure that the file is access only by processes/users who are
    authorized to view that information (can be done with monitoring tools
    to trigger an alert… if your machine or file has been compromised
    you got bigger problems than a single password in a file).
  3. frequently change the credential information (this will reduce the
    value of the information it is compromised)
  4. monitor the services (i.e. database, web, file system, connections)
    and look for suspicious activity

Lastly, it is important to keep in mind that security is a question of
layers… the more you have the better chances you have of not being
compromised…

Jean-Marc
http://m2i3.com


#9

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. :slight_smile: 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. :slight_smile:

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

On Nov 27, 1:40 pm, “Jean-Marc (M2i3.com)” removed_email_address@domain.invalid