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. -- Posted via http://www.ruby-forum.com/.
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
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.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 ---------------------------------------------------------------------- Mon calendrier en ligne : http://www.inma.ucl.ac.be/~majoros/calendar Accents bizarre ? http://www.inma.ucl.ac.be/~majoros/email.html ---------------------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3403 bytes Desc: S/MIME Cryptographic Signature Url : http://wrath.rubyonrails.org/pipermail/rails/attachments/20060609/3bc49cdb/smime.bin
Marcus Ob 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 ? > > Thanks, > Marcus Ob. >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.
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. > > IsakHi 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. -- Posted via http://www.ruby-forum.com/.
On 6/9/06, Marcus Ob <mrqzzz@yahoo.it> wrote:> 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-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
On Jun 9, 2006, at 3:03 AM, Yannick Majoros wrote:> 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. > > 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 usersI 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 > practicalWell, 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
Julian ''Julik'' Tarkhanov
2006-Jun-09 17:57 UTC
[Rails] Securing database from your provider?
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
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.
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
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
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