I have to say I think putting it in the source code is the worst possible option.
If for security reasons (say one of your developers leaves unhappily!) you need to change your database password, I don't think you want to have to change your java source, compile and re-deploy your app in order to achieve this. Its got to be better to have this as some kind of configuration parameter - you just have to make sure you protect the host's configuration properly. Niall ----- Original Message ----- From: "Lucas Gonzalez" <[EMAIL PROTECTED]> To: "Struts Users Mailing List" <[EMAIL PROTECTED]> Sent: Thursday, March 11, 2004 7:07 PM Subject: Re: [OT] Database password > I believe that it will be easier to define a proper security policy in your > production server than trying to hide the password or encrypt it. > > Another option is to hard-code it into your source, but you will loose some > flexibility there. > > Hope that helps > Lucas > > ----- Original Message ----- > From: "Guillermo Meyer" <[EMAIL PROTECTED]> > To: "'Struts Users Mailing List'" <[EMAIL PROTECTED]> > Sent: Thursday, March 11, 2004 3:59 PM > Subject: RE: [OT] Database password > > > Users cant access this file, but the file can be accessed by people that > is not from Information Security area (Seguridad Informática). The > password shouldnt be known neither by the application deployer, nor the > system administrator, but only by Information Security people. > > -----Original Message----- > From: Lucas Gonzalez [mailto:[EMAIL PROTECTED] > Sent: Jueves, 11 de Marzo de 2004 03:56 p.m. > To: Struts Users Mailing List > Subject: Re: [OT] Database password > > > If the problem is the user accesing the plain text file by typing the > URL in the browser... > > a better solution would be to tell apache to hide those files... > > > ----- Original Message ----- > From: "Guillermo Meyer" <[EMAIL PROTECTED]> > To: "'Struts Users Mailing List'" <[EMAIL PROTECTED]> > Sent: Thursday, March 11, 2004 3:49 PM > Subject: [OT] Database password > > > > Hi: > > Our Struts application is currently in production. This applciation > > uses an Oracle Database (we are using DBCP from jakarta). We access > > this database through url, user a password and we need to "hide" the > > production database password. The password is stored in a > > configuration file and is in plain text. > > > > Have you got some "best practices" in this scenario? How are your Java > > > Applications get connected to production databases and how is the > > database password protected? If we encrypt the password with 3DES, how > > > should the key be protected? > > > > Cheers. > > Guillermo. > > > > > > NOTA DE CONFIDENCIALIDAD > > Este mensaje (y sus anexos) es confidencial, esta dirigido > > exclusivamente > a las personas direccionadas en el mail y puede contener informacion > (i)de propiedad exclusiva de Interbanking S.A. o (ii) amparada por el > secreto profesional. Cualquier opinion en el contenido, es exclusiva de > su autor y no representa necesariamente la opinion de Interbanking S.A. > El acceso no autorizado, uso, reproduccion, o divulgacion esta > prohibido. Interbanking S.A no asumira responsabilidad ni obligacion > legal alguna por cualquier informacion incorrecta o alterada contenida > en este mensaje. Si usted ha recibido este mensaje por error, le rogamos > tenga la amabilidad de destruirlo inmediatamente junto con todas las > copias del mismo, notificando al remitente. No debera utilizar, revelar, > distribuir, imprimir o copiar este mensaje ni ninguna de sus partes si > usted no es el destinatario. Muchas gracias. > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > NOTA DE CONFIDENCIALIDAD > Este mensaje (y sus anexos) es confidencial, esta dirigido exclusivamente a > las personas direccionadas en el mail y puede contener informacion (i)de > propiedad exclusiva de Interbanking S.A. o (ii) amparada por el secreto > profesional. Cualquier opinion en el contenido, es exclusiva de su autor y > no representa necesariamente la opinion de Interbanking S.A. El acceso no > autorizado, uso, reproduccion, o divulgacion esta prohibido. Interbanking > S.A no asumira responsabilidad ni obligacion legal alguna por cualquier > informacion incorrecta o alterada contenida en este mensaje. Si usted ha > recibido este mensaje por error, le rogamos tenga la amabilidad de > destruirlo inmediatamente junto con todas las copias del mismo, notificando > al remitente. No debera utilizar, revelar, distribuir, imprimir o copiar > este mensaje ni ninguna de sus partes si usted no es el destinatario. Muchas > gracias. > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
