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 --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
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? On Wed, Nov 26, 2008 at 4:07 PM, pepe <Pepe-gUAqH5+0sKL6V6G2DxALlg@public.gmane.org> 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. > > What would be the easiest way of making this work? > > Thank you. > > Pepe > > >--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
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 On Nov 26, 5:28 pm, "Brian Hogan" <bpho...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> If they''re asking you to encrypt thepasswordin thedatabase.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 DBpasswordin 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 dbpasswordencryptionout of the box. > > Anyone else know a better solution? > > On Wed, Nov 26, 2008 at 4:07 PM, pepe <P...-gUAqH5+0sKL6V6G2DxALlg@public.gmane.org> wrote: > > > Hello. > > > I currently have an application deployed and running and just recently > > I have been asked to encrypt thedatabasepassword. Thepasswordis in > > thedatabase.yml file. > > > What would be the easiest way of making this work? > > > Thank you. > > > Pepe--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
On Wed, Nov 26, 2008 at 8:08 PM, pepe <Pepe-gUAqH5+0sKL6V6G2DxALlg@public.gmane.org> 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 :-)> 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, -- Hassan Schroeder ------------------------ hassan.schroeder-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
On Thu, 27 Nov 2008 13:51:45 +0900, Hassan Schroeder <hassan.schroeder-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:>> 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 :-) >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 --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
On Nov 26, 10:07 pm, pepe <P...-1PhG29ZdMB/g+20BJ0uB2w@public.gmane.org> 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. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
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 On Nov 27, 2:08 am, pepe <P...-1PhG29ZdMB/g+20BJ0uB2w@public.gmane.org> wrote:> 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 > > On Nov 26, 5:28 pm, "Brian Hogan" <bpho...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > If they''re asking you to encrypt thepasswordin thedatabase.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 DBpasswordin 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 dbpasswordencryptionout of the box. > > > Anyone else know a better solution? > > > On Wed, Nov 26, 2008 at 4:07 PM, pepe <P...-gUAqH5+0sKL6V6G2DxALlg@public.gmane.org> wrote: > > > > Hello. > > > > I currently have an application deployed and running and just recently > > > I have been asked to encrypt thedatabasepassword. Thepasswordis in > > > thedatabase.yml file. > > > > What would be the easiest way of making this work? > > > > Thank you. > > > > Pepe--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
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 --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
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 On Nov 27, 1:40 pm, "Jean-Marc (M2i3.com)" <jean-marc.lag...-AvxwWzkCwIQ@public.gmane.org> wrote:> 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-Marchttp://m2i3.com--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---