Asclepio Tagore escribió: Hola,
> Pero les tengo una sugerencia que hace referencia al orden. Sucede que no es > la unica lista en la que estoi registrado y me soprendio lo desordenado que > es esta lista. He notado que hacen mucho top-posting[1], y eso es muy > molesto. Otra cosa que noto es que responden a los mensajes (en general) sin > seguir un mismo hilo de conversación, un ejemplo de ello es el mensaje de la > encuesta linux, de este tengo como cinco mail distintos. Seria bueno que > haya un mayor esfuerzo porque eso no ocurra para que sea todo mas ordenado. Te apoyo totalmente, pero habemos varios que nos cansamos de nadar contra la corriente ... mi alma descansa en la idea de que los top-posters arderán en el fuego del Septiembre Eterno, AOL y Andrea Benk*, pero en esta vida hay que aprender a ignorarlos y poner la otra mejilla (a.k.a. killfile, > /dev/null, etc). PS: Se me llenó /dev/null!! -- Alvaro Herrera http://www.flickr.com/photos/alvherre/ "World domination is proceeding according to plan" (Andrew Morton) From [EMAIL PROTECTED] Thu Dec 6 10:00:37 2007 From: [EMAIL PROTECTED] (Alvaro Herrera) Date: Thu Dec 6 10:03:32 2007 Subject: Ocultar Passwords a produccion. In-Reply-To: <[EMAIL PROTECTED]> References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> Asdtaker escribió: > On Dec 5, 2007 2:10 PM, Alvaro Herrera <[EMAIL PROTECTED]> wrote: > > Lo que mas puedes hacer es que dicho archivo este oculto y que nadie > > (salvo la aplicacion) tenga privilegios para leerlo. > > Exacto, buena practica. Pero aun tengo mi password en un file de > configuracion y debo entregarla al desarrollador/analista. No entiendo. ¿Para que tienes que entregarsela? Solo dale privilegios para ejecutar la rutina de conexion a la BD. El archivo le estará oculto y no podrá obtener la password por esa vía. -- Alvaro Herrera http://www.amazon.com/gp/registry/5ZYLFMCVHXC "I call it GNU/Linux. Except the GNU/ is silent." (Ben Reiter) From [EMAIL PROTECTED] Thu Dec 6 09:33:54 2007 From: [EMAIL PROTECTED] (Ricardo Utreras Estrella) Date: Thu Dec 6 10:04:32 2007 Subject: Ocultar Passwords a produccion. In-Reply-To: <[EMAIL PROTECTED]> References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> Asdtaker escribió: > On Dec 5, 2007 2:10 PM, Alvaro Herrera <[EMAIL PROTECTED]> wrote: > >> Asdtaker escribió: >> >>> Otro problema, y mas grande aun, en cuando tenemos aplicaciones >>> cliente-servidor, con archivos de configuracion en cada cliente, o bien >> (en >>> el caso sql server) odbc, en ese caso no existe manera de encriptar las >>> password, y al menos debe conocerla el desarrollador/analista de la >>> aplicacion y configurarla (digitarla) bien en el codigo (ejecutable) o >> en un >>> archivo de configuracion. Mi problema es que necesito que estas password >> no >>> sean conocidas por nadie, ni siquiera el admin del sistema (password >>> bipartida) y el dia de mañana poder cambiarlas de manera transparente >> para >>> los usuarios. >> Eso es imposible. > > grrrr...lapidario! > >> Ademas, no lograrias nada, porque el administrador de >> la maquina, siendo "root", podria de todos modos detener el servidor y >> levantarlo en el modo que no requiere password, si quisiera robarse tu >> informacion. > > Ok, pero supongamos que asumo ese riesgo y sus consecuencias(mejor, la > organizacion esta dispuesta a...). Ademas, toma medidas precautorias: limita > el acceso fisico al server, no acepta unidades opticas/usb/paralelo, > etc(aunque claro, siempre puede obtener acceso remoto, pero ese eso otro > cuento). > >> >> Las passwords necesariamente deben estar en un archivo en alguna parte. > > Ok, I agree. > >> Lo que mas puedes hacer es que dicho archivo este oculto y que nadie >> (salvo la aplicacion) tenga privilegios para leerlo. > > Exacto, buena practica. Pero aun tengo mi password en un file de > configuracion y debo entregarla al desarrollador/analista. > >> >> -- >> Alvaro Herrera Developer, >> http://www.PostgreSQL.org/ >> "Las cosas son buenas o malas segun las hace nuestra opinión" (Lisias) >> > > > Usa un token (USB u otro) -- Saluda atte., Ricardo Utreras Estrella From [EMAIL PROTECTED] Thu Dec 6 10:04:59 2007 From: [EMAIL PROTECTED] (Wladimir A. Jimenez B.) Date: Thu Dec 6 10:08:02 2007 Subject: Ocultar Passwords a produccion. In-Reply-To: <[EMAIL PROTECTED]> References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> El 6/12/07, Rodrigo Fuentealba <[EMAIL PROTECTED]> escribió: > 2007/12/6, Asdtaker <[EMAIL PROTECTED]>: > > On Dec 5, 2007 2:10 PM, Alvaro Herrera <[EMAIL PROTECTED]> wrote: > > > > > Asdtaker escribió: > > > > > > > Otro problema, y mas grande aun, en cuando tenemos aplicaciones > > > > cliente-servidor, con archivos de configuracion en cada cliente, o bien > > > > (en > > > > el caso sql server) odbc, en ese caso no existe manera de encriptar las > > > > password, y al menos debe conocerla el desarrollador/analista de la > > > > aplicacion y configurarla (digitarla) bien en el codigo (ejecutable) o > > > en un > > > > archivo de configuracion. Mi problema es que necesito que estas password > > > > no > > > > sean conocidas por nadie, ni siquiera el admin del sistema (password > > > > bipartida) y el dia de mañana poder cambiarlas de manera transparente > > > > para los usuarios. > > > > > > Eso es imposible. > > Por lo que entiendo, tienes aplicaciones hechas por ti/tu empresa cuya > información no quieres pasársela a tus clientes. > > Puedes al menos intentar hacer más difícil el tema; si tu programa es > compilado, haz un módulo (qué se yo, un .so, .dll o lo que venga al > caso) que arme la ConnectionString a partir de un par de funciones > (ejem, el ejemplo más chanta que se me ocurre sería ROT13), y guardas > las configuraciones en los equipos cliente en un archivo cifrado. > > Si es interpretado, es más difícil (excepto con las páginas PHP > ofuscadas), pero igual podrías ver qué ocurre. > > > grrrr...lapidario! > > > > > Ademas, no lograrias nada, porque el administrador de > > > la maquina, siendo "root", podria de todos modos detener el servidor y > > > levantarlo en el modo que no requiere password, si quisiera robarse tu > > > informacion. > > > Ok, pero supongamos que asumo ese riesgo y sus consecuencias(mejor, la > > organizacion esta dispuesta a...). Ademas, toma medidas precautorias: limita > > el acceso fisico al server, no acepta unidades opticas/usb/paralelo, > > etc(aunque claro, siempre puede obtener acceso remoto, pero ese eso otro > > cuento). > > Reducir al mínimo la superficie de exposición del servidor es una muy > buena medida, pero siempre vas a trabarte en cosas como "es que > necesito que haga respaldos", "necesito que haga tal cosa", etc. El > hecho de que tu información esté en el edificio de tu cliente y no > bajo tu control ya significa que están ante gente extraña y > maldadosa... por lo tanto es un problema. > > -- > Rodrigo Fuentealba > > Bueno Adstaker, por lo visto una solicion asi al problema no existe. Lo que si siempre se puede hacer es cifrar el archivo de contraseña que entregas con una libreria para la conexion a db cerrarda. Por le que me imagino tus aplicaciones son VB, o ASP, en estos dos casos puedes contruir una dll, que se encargue de abrir la conexion, que en ella este cifrada la contraseña, y los desarrolladores solo se conecten por este medio a las bases de datos. Me parace el unico medio de ocultar informaciòn, no digamos que es 100% seguro, pero te permite un poco de seguridad. A y cuando cambies la clave de la cuenta de accesos de cambiar la dll. Atte Wladimir A. Jiménez B.
