Ocultar Passwords a produccion.

Wladimir A. Jimenez B. wjimenezb en gmail.com
Jue Dic 6 10:04:59 CLST 2007


El 6/12/07, Rodrigo Fuentealba <darkprox en gmail.com> escribió:
> 2007/12/6, Asdtaker <asdtaker en gmail.com>:
> > On Dec 5, 2007 2:10 PM, Alvaro Herrera <alvherre en alvh.no-ip.org> 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.



Más información sobre la lista de distribución Linux