Securing database from your provider?

Rails
1

Hi.
If i had a RoR application dealing with very reserved personal
informations about my customers, if my hosting provider would like to, i
guess it would be easy for him to steal the data by simply peeking the
username and password inside the database.yml file.

Is there a way to hide the database password from indiscrete eyes ?

Thanks,
Marcus Ob.

2

On 6/9/06, Marcus Ob [email protected] wrote:

Hi.
If i had a RoR application dealing with very reserved personal
informations about my customers, if my hosting provider would like to, i
guess it would be easy for him to steal the data by simply peeking the
username and password inside the database.yml file.

Is there a way to hide the database password from indiscrete eyes ?

If your application can read the data, anyone with full access to the
application can as well. This holds for any system, and is why for
instance DRM doesn’t work.

Isak

3

Isak H. wrote:

application can as well. This holds for any system, and is why for
instance DRM doesn’t work.

If everything in the database is encrypted using a key that you supply
when connecting to the application, your provider won’t be able to read
anything, but there are some drawbacks:

  • you either need to have multiple-key encryption techniques (which I
    am not aware of) or to have the same key for all users
  • if you need to change the key, you have to decrypt, then re-encrypt
    the whole database with the new key, which is not really practical

So, in short: it would be difficult, you have to trust your hosting
provider. Naturally, you could have your own server.

–

Yannick M. http://www.inma.ucl.ac.be/~majoros
Informaticien UCL/INMA-MEMA
4, avenue G. Lemaître
B-1348 Louvain-la-Neuve
Tel: +32-10-47.80.10
Fax: +32-10-47.21.80

4

Marcus Ob wrote:

Get a Housing (Your own server with your OS (OpenBSD i’ll say), and
console
access locked) in a datacenter.

Security is possible, but it has it’ price.

5

Isak H. wrote:

On 6/9/06, Marcus Ob [email protected] wrote:

Hi.
If i had a RoR application dealing with very reserved personal
informations about my customers, if my hosting provider would like to, i
guess it would be easy for him to steal the data by simply peeking the
username and password inside the database.yml file.

Is there a way to hide the database password from indiscrete eyes ?

If your application can read the data, anyone with full access to the
application can as well. This holds for any system, and is why for
instance DRM doesn’t work.

Isak

Hi Isak,
well i agree that DRM is utopistic and anything can be hacked, but i
hoped someone had a trick to make life harder to curious providers,
instead of gifting them with a cleanly visible password…

I guess just found something i was looking for here:
http://blog.lathi.net/articles/2006/03/02/config-database-yml-goodness-for-teams

It’ not bulletproof but it can complicate the life of curious and
not-so-ruby-expert providers.

Marcus Ob.

6

On Jun 9, 2006, at 3:03 AM, Yannick M. wrote:

Is there a way to hide the database password from indiscrete eyes ?
I am not aware of) or to have the same key for all users
I believe PGP supports multi password encryption/decryption.

http://tinyurl.com/rnfxt

“For extra high security, you can split keys among multiple people;
when you need to sign or decrypt with a split key, a designated
number of participating shareholders must sign.”

  • if you need to change the key, you have to decrypt, then re-
    encrypt the whole database with the new key, which is not really
    practical

Well, you could encrypt the DB password (which never changes) and
occassionally re-encrypt it with a different password.

The biggest disadvantage (though pretty much a requirement if serious
security is your concern) is that the application cannot auto-start.

–
– Tom M.

7

On 9-jun-2006, at 18:45, Tom M. wrote:

The biggest disadvantage (though pretty much a requirement if
serious security is your concern) is that the application cannot
auto-start.

Or just run all the database on your server and connect to it from
the application via an SSL socket… but the question actually is
absurd. There is (currently) no way to obfuscate/encrypt Ruby code,
so if someone can see your code he will be able to get access to your
database.

“Get your own server” is the answer here.

Julian ‘Julik’ Tarkhanov
please send all personal mail to
me at julik.nl

8

On 6/9/06, Marcus Ob [email protected] wrote:

If your application can read the data, anyone with full access to the
I guess just found something i was looking for here:
http://blog.lathi.net/articles/2006/03/02/config-database-yml-goodness-for-teams

It’ not bulletproof but it can complicate the life of curious and
not-so-ruby-expert providers.

Marcus Ob.

Keeping the password out of your VCS is a good idea, yes. It’s
probably the only thing protecting you from other customers of that
provider.

But there’s no point in hiding it from the hosting company. They don’t
need a password to access your db anyway, and even if you encrypt the
data, they will be able to access the key if your app can.

Hosting the app yourself is no magic bullet either. You’d still have
to find someone trustworthy to keep that server running and secure.

Good luck,
Isak

9

Marcus Ob wrote the following on 09.06.2006 11:24 :

Hi.
If i had a RoR application dealing with very reserved personal
informations about my customers, if my hosting provider would like to, i
guess it would be easy for him to steal the data by simply peeking the
username and password inside the database.yml file.

Is there a way to hide the database password from indiscrete eyes ?

Hiding the password doesn’t protect your database content if the hosting
provider has physical access to the system.

One wild idea, you could:

  • use a DRB service designed to hold an encryption key and serve it to
    your Rails app,
  • set an admin page where you can enter the encryption key which will
    store call the DRB it on the DRB service,
  • then for each field you want to protect, you access the DRB service to
    get the encryption key at write and read time (caching the key in a
    global variable could help performance).

To break this, they will have to hire a Ruby coder to either :

  • modify the admin page (and even find it if you access it by SSL) in
    order to intercept the key,
  • find out from the code how to access the DRB service to get the key
    once entered.

But if they put the system offline for data-mining, they’ll only find
encrypted data in the database.

The obvious problem is that each time the DRB service is restarted
you’ll have to put the key back.
You could script the key refreshing on one system you have complete
control of. It would monitor the availability of your application with
safeguards not allowing automatic key refreshing if the system was down
too long and may have been tampered with.

There are other techniques but they only deal with other levels of
obfuscation, if they are smart enough to let a coder access the system
without downtime you’re out of luck.

This obviously looks a lot like DRM techniques (with the same kind of
problems).

Lionel.

10

On 6/9/06, Lionel B. [email protected] wrote:

Marcus Ob wrote the following on 09.06.2006 11:24 :
To break this, they will have to hire a Ruby coder to either :

  • modify the admin page (and even find it if you access it by SSL) in
    order to intercept the key,
  • find out from the code how to access the DRB service to get the key
    once entered.

Or they could reset the password… Or access it from root. Or dump
the database data and import it into another system they do have
authentication permission into… They are the admins, they are
gods… If you don’t trust them, I would be looking into self-hosting
or getting another provider…

-Curtis

11

Curtis wrote the following on 09.06.2006 22:58 :

On 6/9/06, Lionel B. [email protected] wrote:

Marcus Ob wrote the following on 09.06.2006 11:24 :
To break this, they will have to hire a Ruby coder to either :

  • modify the admin page (and even find it if you access it by SSL) in
    order to intercept the key,
  • find out from the code how to access the DRB service to get the key
    once entered.

Or they could reset the password… Or access it from root.

The DRB service wouldn’t store the database password but an encryption
key: this is meant to make it impossible to get at the encrypted data
with only the disk: they must get at the in-memory encryption key, which
would require Ruby-fluency from the person trying to break this and
prevent any successful attempt if the machine is powered down at any
point during the analysis.

It’s only a nice obfuscation technique that popped into my mind, nothing
foolproof.

I don’t even have a use case for this myself: I don’t see how you can
tell users that you guarantee the safety of their data if the hosting
provider doesn’t do the same for you. If you aren’t covered by contract
for any litigation that would come from the hosting provider leaking
your data, you may put yourself into serious troubles.

Lionel

12

On 6/9/06, Lionel B. [email protected] wrote:

The DRB service wouldn’t store the database password but an encryption
key: this is meant to make it impossible to get at the encrypted data
with only the disk: they must get at the in-memory encryption key, which
would require Ruby-fluency from the person trying to break this and
prevent any successful attempt if the machine is powered down at any
point during the analysis.

I’m sorry, I sounded a little smug there. I didn’t mean to. It’s a
really good technique, my only point was that if someone else owns the
server there isn’t a whole lot you can do other than ensure you will
press charges if anything happens. :slight_smile:

This is why I would never put incredibly secure data on a shared
server. You just owe it to your clients / customers to not. I also
state in the privacy agreement that confidential data should never be
kept in a system that is not SSL protected and on a dedicated, locked,
non-shared server. Even if the database backups aren’t tightly
secured, you don’t want the data in there…

-Curtis

13

Thank you all for your opinions and suggestions.
I’ll keep them all in mind.

Best regards,
happy week-end.
Marcu Ob