Forum: Ruby on Rails Securing database from your provider?

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
02e5064be65a36d46d46992c382509ea?d=identicon&s=25 Marcus Ob (mrqzzz)
on 2006-06-09 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 ?

Thanks,
Marcus Ob.
5233478c51a92b6a1a5c970cbf3a42f3?d=identicon&s=25 Isak Hansen (Guest)
on 2006-06-09 11:59
(Received via mailing list)
On 6/9/06, Marcus Ob <mrqzzz@yahoo.it> 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
71cd7be67932c4ef1f84a346dd7c223f?d=identicon&s=25 Yannick Majoros (Guest)
on 2006-06-09 12:05
(Received via mailing list)
Isak Hansen 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 Majoros 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
C7d5bc5b054035d95f287797c2595694?d=identicon&s=25 Matias Surdi (Guest)
on 2006-06-09 12:14
(Received via mailing list)
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.
02e5064be65a36d46d46992c382509ea?d=identicon&s=25 Marcus Ob (mrqzzz)
on 2006-06-09 12:44
Isak Hansen wrote:
> On 6/9/06, Marcus Ob <mrqzzz@yahoo.it> 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-d...

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


Marcus Ob.
5233478c51a92b6a1a5c970cbf3a42f3?d=identicon&s=25 Isak Hansen (Guest)
on 2006-06-09 14:41
(Received via mailing list)
On 6/9/06, Marcus Ob <mrqzzz@yahoo.it> 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-d...
>
> 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
59de94a56fd2c198f33d9515d1c05961?d=identicon&s=25 Tom Mornini (Guest)
on 2006-06-09 18:48
(Received via mailing list)
On Jun 9, 2006, at 3:03 AM, Yannick Majoros 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 Mornini
A2b2f4ee23989dc68529baef9cbddcd6?d=identicon&s=25 Julian 'Julik' Tarkhanov (Guest)
on 2006-06-09 20:00
(Received via mailing list)
On 9-jun-2006, at 18:45, Tom Mornini 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
Bef7ff8a0537495a1876ffebdc9f8e51?d=identicon&s=25 Lionel Bouton (Guest)
on 2006-06-09 21:17
(Received via mailing list)
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.
39c5254d0a798765f37ac215fa6e0fc7?d=identicon&s=25 Curtis Spendlove (cuspendlove)
on 2006-06-09 23:00
(Received via mailing list)
On 6/9/06, Lionel Bouton <lionel-subscription@bouton.name> 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
Bef7ff8a0537495a1876ffebdc9f8e51?d=identicon&s=25 Lionel Bouton (Guest)
on 2006-06-09 23:23
(Received via mailing list)
Curtis wrote the following on 09.06.2006 22:58 :
> On 6/9/06, Lionel Bouton <lionel-subscription@bouton.name> 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
39c5254d0a798765f37ac215fa6e0fc7?d=identicon&s=25 Curtis Spendlove (cuspendlove)
on 2006-06-10 00:23
(Received via mailing list)
On 6/9/06, Lionel Bouton <lionel-subscription@bouton.name> 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.  :)

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
02e5064be65a36d46d46992c382509ea?d=identicon&s=25 Marcus Ob (mrqzzz)
on 2006-06-10 19:57
Thank you all for your opinions and suggestions.
I'll keep them all in mind.

Best regards,
happy week-end.
Marcu Ob
This topic is locked and can not be replied to.