permisos sobre triguer

Hola amigos
Tengo un triguer (trg_usuarios) que genera contraseñas y no quiero que
los usuarios desarrolladores tengan acceso para ver el código fuente,
por que tengo una palabra secreta que uso para generar contraseñas
encriptadas como semilla de esta manera md5 ('semilla' |'contraseña)
Pero a pesar de que no tienen permiso sobre los esquemas ni nada mas
pueden ver el código fuente del triguer desde EMS y PgAdmin, naulando
el secreto....

ya intente con esto:

REVOKE SELECT ON TABLE pg_trigger FROM public;

pero con esto se restringe el acceso a todos los triguers y yo solo
quiero quitarles el acceso a mi triguer de contraseñas (trg_usuarios)
tiene alguna otra idea para hacer esto?????

--
EMPRESA NACIONAL DE ELECTRICIDAD
www.ende.bo
Tel.: (591-4) 4520253 - 4520228
Fax: (591-4) 4520318
---------------------------------------------------------------------------------
Este mensaje ha sido analizado automaticamente por el MailScanner de ENDE
y no han sido detectados virus ni otros contenidos peligrosos.

Rensi Arteaga Copari escribió:
> Hola amigos
> Tengo un triguer (trg_usuarios) que genera contraseñas y no quiero
> que los usuarios desarrolladores tengan acceso para ver el código
> fuente,
> por que tengo una palabra secreta que uso para generar contraseñas
> encriptadas como semilla de esta manera md5 ('semilla'
> |'contraseña)

> tiene alguna otra idea para hacer esto?????

Usa otro mecanismo para esconder tu secreto. Esta implementación no es
buena de todas formas. A todo esto, ¿cuál es la palabra secreta? ¿La
semilla? Si es así, entonces no es necesario esconderla; la semilla no
tiene mucha necesidad de ser secreta. (Obviamente no debes usar la
misma semilla para todas las contraseñas)

--
Alvaro Herrera http://www.amazon.com/gp/registry/3BP7BYG9PUGI8
"Las mujeres son como hondas: mientras más resistencia tienen,
más lejos puedes llegar con ellas" (Jonas Nightingale, Leap of Faith)

El 25/03/10 15:10, Alvaro Herrera escribió:
> Rensi Arteaga Copari escribió:
>
>> Hola amigos
>> Tengo un triguer (trg_usuarios) que genera contraseñas y no quiero
>> que los usuarios desarrolladores tengan acceso para ver el código
>> fuente,
>> por que tengo una palabra secreta que uso para generar contraseñas
>> encriptadas como semilla de esta manera md5 ('semilla'
>> |'contraseña)
>>
>
>
>> tiene alguna otra idea para hacer esto?????
>>
>
> Usa otro mecanismo para esconder tu secreto. Esta implementación no es
> buena de todas formas. A todo esto, ¿cuál es la palabra secreta? ¿La
> semilla? Si es así, entonces no es necesario esconderla; la semilla no
> tiene mucha necesidad de ser secreta. (Obviamente no debes usar la
> misma semilla para todas las contraseñas)
>
>

Si es la semilla y la repetía para todas las contraseñas,
pero me diste otra idea, mejor creo una tabla de semillas, luego
consulto esta tabla para generar las contraseñas
y para evitar que los desarrolladores vean su contenido solo les quito
el permiso de lectura sobre esa tabla

Muchas gracias

--
EMPRESA NACIONAL DE ELECTRICIDAD
www.ende.bo
Tel.: (591-4) 4520253 - 4520228
Fax: (591-4) 4520318
---------------------------------------------------------------------------------
Este mensaje ha sido analizado automaticamente por el MailScanner de ENDE
y no han sido detectados virus ni otros contenidos peligrosos.

El día 25 de marzo de 2010 10:51, Rensi Arteaga Copari
<rarteaga(at)ende(dot)bo> escribió:
> Hola amigos
> Tengo un triguer (trg_usuarios) que genera contraseñas y no quiero que los
> usuarios desarrolladores tengan acceso para ver el código fuente,
> por que tengo una palabra secreta que uso para generar contraseñas
> encriptadas como semilla de esta manera  md5 ('semilla' |'contraseña)
> Pero a pesar de que no tienen permiso sobre los esquemas ni nada mas pueden
> ver el código fuente del triguer  desde EMS y PgAdmin, naulando el
> secreto....
>
> ya intente con esto:
>
>  REVOKE SELECT ON TABLE pg_trigger FROM public;
>
>
> pero con esto se restringe el acceso a todos los triguers  y yo solo quiero
> quitarles el acceso a mi triguer de contraseñas (trg_usuarios)
> tiene alguna otra idea para hacer esto?????
>
>

Tenés un problema grave, ya que, por lo que contás, estás dándole
permisos de accesso a datos de producción a los desarrolladores. Hacé
un entorno de desarrollo y otro de producción donde sólo el DBA tenga
acceso. Con eso será suficiente y, además, cumplimentarás un punto de
auditoría.

--
Silvio Quadri

El 25/03/10 15:20, Silvio Quadri escribió:
> El día 25 de marzo de 2010 10:51, Rensi Arteaga Copari
> <rarteaga(at)ende(dot)bo> escribió:
>
>> Hola amigos
>> Tengo un triguer (trg_usuarios) que genera contraseñas y no quiero que los
>> usuarios desarrolladores tengan acceso para ver el código fuente,
>> por que tengo una palabra secreta que uso para generar contraseñas
>> encriptadas como semilla de esta manera md5 ('semilla' |'contraseña)
>> Pero a pesar de que no tienen permiso sobre los esquemas ni nada mas pueden
>> ver el código fuente del triguer desde EMS y PgAdmin, naulando el
>> secreto....
>>
>> ya intente con esto:
>>
>> REVOKE SELECT ON TABLE pg_trigger FROM public;
>>
>>
>> pero con esto se restringe el acceso a todos los triguers y yo solo quiero
>> quitarles el acceso a mi triguer de contraseñas (trg_usuarios)
>> tiene alguna otra idea para hacer esto?????
>>
>>
>>
>
> Tenés un problema grave, ya que, por lo que contás, estás dándole
> permisos de accesso a datos de producción a los desarrolladores. Hacé
> un entorno de desarrollo y otro de producción donde sólo el DBA tenga
> acceso. Con eso será suficiente y, además, cumplimentarás un punto de
> auditoría.
>
>
>
>
Gracias Silvio tienes razon, ya tengo separado la base de datos en
tres ambientes uno para desarrollo, otro de prueba y otros de operación
pero el DBA no abastece por si solo para realizar el mantenimiento de
la base de datos
y es necesario la ayuda de un par de personas (de las que ayudaron a
desarrollar el sistema), un grupo al que llame "desarrolladores", para
evitar confusiones mejor les llamo dba_auxiliares)

--
EMPRESA NACIONAL DE ELECTRICIDAD
www.ende.bo
Tel.: (591-4) 4520253 - 4520228
Fax: (591-4) 4520318
---------------------------------------------------------------------------------
Este mensaje ha sido analizado automaticamente por el MailScanner de ENDE
y no han sido detectados virus ni otros contenidos peligrosos.

El día 25 de marzo de 2010 16:26, Rensi Arteaga Copari
<rarteaga(at)ende(dot)bo> escribió:
> El 25/03/10 15:20, Silvio Quadri escribió:
>>
>> El día 25 de marzo de 2010 10:51, Rensi Arteaga Copari
>> <rarteaga(at)ende(dot)bo>  escribió:
>>
>>>
>>> Hola amigos
>>> Tengo un triguer (trg_usuarios) que genera contraseñas y no quiero que
>>> los
>>> usuarios desarrolladores tengan acceso para ver el código fuente,
>>> por que tengo una palabra secreta que uso para generar contraseñas
>>> encriptadas como semilla de esta manera  md5 ('semilla' |'contraseña)
>>> Pero a pesar de que no tienen permiso sobre los esquemas ni nada mas
>>> pueden
>>> ver el código fuente del triguer  desde EMS y PgAdmin, naulando el
>>> secreto....
>>>
>>> ya intente con esto:
>>>
>>>  REVOKE SELECT ON TABLE pg_trigger FROM public;
>>>
>>>
>>> pero con esto se restringe el acceso a todos los triguers  y yo solo
>>> quiero
>>> quitarles el acceso a mi triguer de contraseñas (trg_usuarios)
>>> tiene alguna otra idea para hacer esto?????
>>>
>>>
>>>
>>
>> Tenés un problema grave, ya que, por lo que contás, estás dándole
>> permisos de accesso a datos de producción a los desarrolladores. Hacé
>> un entorno de desarrollo y otro de producción donde sólo el DBA tenga
>> acceso. Con eso será suficiente y, además, cumplimentarás un punto de
>> auditoría.
>>
>>
>>
>>
>
> Gracias Silvio tienes   razon,  ya tengo separado la base de datos en tres
> ambientes uno para desarrollo, otro de prueba y otros de operación
> pero el DBA  no abastece por si solo  para realizar el mantenimiento de la
> base de datos
> y es necesario  la ayuda de un par de personas (de las que ayudaron a
> desarrollar el sistema),  un grupo al que llame "desarrolladores",  para
> evitar  confusiones mejor les llamo dba_auxiliares)
>
>

En ese contexto, no pierdas tiempo implementando medidas de seguridad
adicionales, tarde o temprano te van a descubrir ... Hubiera sido más
simple que les ocultaras la tabla de usuarios y listo.
Silvio

El 25/03/10 15:39, Silvio Quadri escribió:
> El día 25 de marzo de 2010 16:26, Rensi Arteaga Copari
> <rarteaga(at)ende(dot)bo> escribió:
>
>> El 25/03/10 15:20, Silvio Quadri escribió:
>>
>>> El día 25 de marzo de 2010 10:51, Rensi Arteaga Copari
>>> <rarteaga(at)ende(dot)bo> escribió:
>>>
>>>
>>>> Hola amigos
>>>> Tengo un triguer (trg_usuarios) que genera contraseñas y no quiero que
>>>> los
>>>> usuarios desarrolladores tengan acceso para ver el código fuente,
>>>> por que tengo una palabra secreta que uso para generar contraseñas
>>>> encriptadas como semilla de esta manera md5 ('semilla' |'contraseña)
>>>> Pero a pesar de que no tienen permiso sobre los esquemas ni nada mas
>>>> pueden
>>>> ver el código fuente del triguer desde EMS y PgAdmin, naulando el
>>>> secreto....
>>>>
>>>> ya intente con esto:
>>>>
>>>> REVOKE SELECT ON TABLE pg_trigger FROM public;
>>>>
>>>>
>>>> pero con esto se restringe el acceso a todos los triguers y yo solo
>>>> quiero
>>>> quitarles el acceso a mi triguer de contraseñas (trg_usuarios)
>>>> tiene alguna otra idea para hacer esto?????
>>>>
>>>>
>>>>
>>>>
>>> Tenés un problema grave, ya que, por lo que contás, estás dándole
>>> permisos de accesso a datos de producción a los desarrolladores. Hacé
>>> un entorno de desarrollo y otro de producción donde sólo el DBA tenga
>>> acceso. Con eso será suficiente y, además, cumplimentarás un punto de
>>> auditoría.
>>>
>>>
>>>
>>>
>>>
>> Gracias Silvio tienes razon, ya tengo separado la base de datos en tres
>> ambientes uno para desarrollo, otro de prueba y otros de operación
>> pero el DBA no abastece por si solo para realizar el mantenimiento de la
>> base de datos
>> y es necesario la ayuda de un par de personas (de las que ayudaron a
>> desarrollar el sistema), un grupo al que llame "desarrolladores", para
>> evitar confusiones mejor les llamo dba_auxiliares)
>>
>>
>>
> En ese contexto, no pierdas tiempo implementando medidas de seguridad
> adicionales, tarde o temprano te van a descubrir ... Hubiera sido más
> simple que les ocultaras la tabla de usuarios y listo.
> Silvio
>
>

Es mas fácil así, también lo pensé, pero como la seguridad no fue
pensada desde el diseño de la aplicación
las tabla de usuarios es referenciada por todos los procesos almacenados
y dejan de funcionar si les quito permiso de consulta sobre esta
tabla.................... (lo mejor hubiera sido utilizar una vista
con lo id_usuario y su nombre)

Sin mecanismos adicionales necesitaría quitar permisos por columnas
(com Label Security de ORACLE)

--
EMPRESA NACIONAL DE ELECTRICIDAD
www.ende.bo
Tel.: (591-4) 4520253 - 4520228
Fax: (591-4) 4520318
---------------------------------------------------------------------------------
Este mensaje ha sido analizado automaticamente por el MailScanner de ENDE
y no han sido detectados virus ni otros contenidos peligrosos.

Rensi Arteaga Copari escribió:
> El 25/03/10 15:10, Alvaro Herrera escribió:

> >Usa otro mecanismo para esconder tu secreto. Esta implementación no es
> >buena de todas formas. A todo esto, ¿cuál es la palabra secreta? ¿La
> >semilla? Si es así, entonces no es necesario esconderla; la semilla no
> >tiene mucha necesidad de ser secreta. (Obviamente no debes usar la
> >misma semilla para todas las contraseñas)
>
> Si es la semilla y la repetía para todas las contraseñas,
> pero me diste otra idea, mejor creo una tabla de semillas, luego
> consulto esta tabla para generar las contraseñas
> y para evitar que los desarrolladores vean su contenido solo les
> quito el permiso de lectura sobre esa tabla

¿Por qué no generas la semilla aleatoriamente cada vez?

--
Alvaro Herrera http://www.flickr.com/photos/alvherre/
Thou shalt check the array bounds of all strings (indeed, all arrays), for
surely where thou typest "foo" someone someday shall type
"supercalifragilisticexpialidocious" (5th Commandment for C programmers)

El 26/03/10 10:41, Alvaro Herrera escribió:
> Rensi Arteaga Copari escribió:
>
>> El 25/03/10 15:10, Alvaro Herrera escribió:
>>
>
>>> Usa otro mecanismo para esconder tu secreto. Esta implementación no es
>>> buena de todas formas. A todo esto, ¿cuál es la palabra secreta? ¿La
>>> semilla? Si es así, entonces no es necesario esconderla; la semilla no
>>> tiene mucha necesidad de ser secreta. (Obviamente no debes usar la
>>> misma semilla para todas las contraseñas)
>>>
>> Si es la semilla y la repetía para todas las contraseñas,
>> pero me diste otra idea, mejor creo una tabla de semillas, luego
>> consulto esta tabla para generar las contraseñas
>> y para evitar que los desarrolladores vean su contenido solo les
>> quito el permiso de lectura sobre esa tabla
>>
> ¿Por qué no generas la semilla aleatoriamente cada vez?
>
>

El momento de autentificar los usuarios de la aplicación desde el
servidor web
necesito conocer la semilla con la que se creo la contraseña en base de
datos, para concatenarla con la contraseña que provee el usuario y
crear una conexión con la BD
Para eso la tengo que tener almacenada en algún lugar (código fuente o
alguna tabla).

Lo hago así :

contrasena_usuario -> la que proporciona le usuario
a momento de autentificarse
md5(contrasema_usuario) -> esto lo almaceno en
mi tabla propia de usuarios de mi sistema
md5 (semilla || md5( contrasena_usuario)) -> esto
para conectar con la base de datos

cada usuario del sistema tiene una contraseña de base de datos

_

saludos

--
EMPRESA NACIONAL DE ELECTRICIDAD
www.ende.bo
Tel.: (591-4) 4520253 - 4520228
Fax: (591-4) 4520318
---------------------------------------------------------------------------------
Este mensaje ha sido analizado automaticamente por el MailScanner de ENDE
y no han sido detectados virus ni otros contenidos peligrosos.

Rensi Arteaga Copari escribió:

> El momento de autentificar los usuarios de la aplicación desde el
> servidor web
> necesito conocer la semilla con la que se creo la contraseña en base
> de datos, para concatenarla con la contraseña que provee el usuario
> y crear una conexión con la BD
> Para eso la tengo que tener almacenada en algún lugar (código
> fuente o alguna tabla).

Huh, claro, la almacenas junto con la password (o en otra columna). No
hay necesidad de que sea secreta; la semilla es sólo para alterar el
resultado del hash, para evitar que dos passwords iguales tengan el
mismo hash. (Esto impide ataques de diccionario, por ej. usando google
para encontrar el string de algun md5).

--
Alvaro Herrera Valdivia, Chile ICBM: S 39º 48' 55.3", W 73º 15' 24.7"
"[PostgreSQL] is a great group; in my opinion it is THE best open source
development communities in existence anywhere." (Lamar Owen)

El 26/03/10 11:34, Alvaro Herrera escribió:
> Rensi Arteaga Copari escribió:
>
>
>> El momento de autentificar los usuarios de la aplicación desde el
>> servidor web
>> necesito conocer la semilla con la que se creo la contraseña en base
>> de datos, para concatenarla con la contraseña que provee el usuario
>> y crear una conexión con la BD
>> Para eso la tengo que tener almacenada en algún lugar (código
>> fuente o alguna tabla).
>>
> Huh, claro, la almacenas junto con la password (o en otra columna). No
> hay necesidad de que sea secreta; la semilla es sólo para alterar el
> resultado del hash, para evitar que dos passwords iguales tengan el
> mismo hash. (Esto impide ataques de diccionario, por ej. usando google
> para encontrar el string de algun md5).
>
>
Gracias Alvaro, tienes razón: entonces almacenaría la semilla aleatoria
en la tabla junto con el usuario al que corresponde
Así también se evita que por observacion determinen que usuarios tienen
la misma contraseña

--
EMPRESA NACIONAL DE ELECTRICIDAD
www.ende.bo
Tel.: (591-4) 4520253 - 4520228
Fax: (591-4) 4520318
---------------------------------------------------------------------------------
Este mensaje ha sido analizado automaticamente por el MailScanner de ENDE
y no han sido detectados virus ni otros contenidos peligrosos.

>>
> Gracias Alvaro, tienes razón: entonces almacenaría la semilla aleatoria
> en la tabla junto con el usuario al que corresponde
> Así también se evita que por observacion determinen que usuarios tienen la
> misma contraseña
>

Algo que utilizo (que sería "similar" a generar una semilla aleatoria pero
sin utilizar un campo adicional) es utilizar como semilla el nombre del
usuario, con eso (al igual que generar semillas aleatorias) te eliminas el
problema de identificar un password válido cuando los hash son iguales o
incluso que se pueda copiar el hash de otro usuario conociendo su password.

Atentamente,

RAUL DUQUE
Bogotá, Colombia

Me parece mejor la semilla aleatoria por que un usuario que conozca el
mecanismos
tendría menos posibilidades de ingresar a la base de datos directamente

saludos

El 26/03/10 12:33, Raúl Andrés Duque Murillo escribió:
>>>
>> Gracias Alvaro, tienes razón: entonces almacenaría la semilla aleatoria
>> en la tabla junto con el usuario al que corresponde
>> Así también se evita que por observacion determinen que usuarios
>> tienen la misma contraseña
>>
>
> Algo que utilizo (que sería "similar" a generar una semilla aleatoria
> pero sin utilizar un campo adicional) es utilizar como semilla el
> nombre del usuario, con eso (al igual que generar semillas aleatorias)
> te eliminas el problema de identificar un password válido cuando los
> hash son iguales o incluso que se pueda copiar el hash de otro usuario
> conociendo su password.
>
> Atentamente,
>
> RAUL DUQUE
> Bogotá, Colombia
> --
> TIP 9: visita nuestro canal de IRC #postgresql-es en irc.freenode.net
>

--
EMPRESA NACIONAL DE ELECTRICIDAD
www.ende.bo
Tel.: (591-4) 4520253 - 4520228
Fax: (591-4) 4520318
---------------------------------------------------------------------------------
Este mensaje ha sido analizado automaticamente por el MailScanner de ENDE
y no han sido detectados virus ni otros contenidos peligrosos.

Rensi Arteaga Copari escribió:
> Me parece mejor la semilla aleatoria por que un usuario que conozca
> el mecanismos
> tendría menos posibilidades de ingresar a la base de datos directamente

Esto me parece un temor sin fundamento. Se supone que la contraseña
propiamente tal es la parte no adivinable. Si realmente tienes tanto
temor de que te adivinen las contraseñas, quizás deberías considerar
otro mecanismo de autentificación (doble token)

--
Alvaro Herrera http://www.amazon.com/gp/registry/DXLWNGRJD34J
"Most hackers will be perfectly comfortable conceptualizing users as entropy
sources, so let's move on." (Nathaniel Smith)

Rensi Arteaga Copari wrote:
> El 29/03/10 15:49, Alvaro Herrera escribió:
> >Rensi Arteaga Copari escribió:
> >>Me parece mejor la semilla aleatoria por que un usuario que conozca
> >>el mecanismos
> >>tendría menos posibilidades de ingresar a la base de datos directamente
> >Esto me parece un temor sin fundamento. Se supone que la contraseña
> >propiamente tal es la parte no adivinable. Si realmente tienes tanto
> >temor de que te adivinen las contraseñas, quizás deberías considerar
> >otro mecanismo de autentificación (doble token)
> >
> Lamento no haber respondido antes pero estaba de viaje.
> El mayor problema no son los usuarios externos, son los dba_auxiliares,

Eso no cambia mi argumento ...

> Ademas hay una persona de seguridad que se encarga de hacer pruebas
> de intrusión
> y solo trato de resolver los problemas que me señalo recordemos que
> la seguridad es igual a tu eslabon más débil

¿Y cuál es el problema que te señaló?

--
Alvaro Herrera http://planet.postgresql.org/
"Hackers share the surgeon's secret pleasure in poking about in gross innards,
the teenager's secret pleasure in popping zits." (Paul Graham)

El 07/04/10 16:30, Alvaro Herrera escribió:
> Rensi Arteaga Copari wrote:
>
>> El 29/03/10 15:49, Alvaro Herrera escribió:
>>
>>> Rensi Arteaga Copari escribió:
>>>
>>>> Me parece mejor la semilla aleatoria por que un usuario que conozca
>>>> el mecanismos
>>>> tendría menos posibilidades de ingresar a la base de datos directamente
>>>>
>>> Esto me parece un temor sin fundamento. Se supone que la contraseña
>>> propiamente tal es la parte no adivinable. Si realmente tienes tanto
>>> temor de que te adivinen las contraseñas, quizás deberías considerar
>>> otro mecanismo de autentificación (doble token)
>>>
>>>
>> Lamento no haber respondido antes pero estaba de viaje.
>> El mayor problema no son los usuarios externos, son los dba_auxiliares,
>>
> Eso no cambia mi argumento ...
>
>
>> Ademas hay una persona de seguridad que se encarga de hacer pruebas
>> de intrusión
>> y solo trato de resolver los problemas que me señalo recordemos que
>> la seguridad es igual a tu eslabon más débil
>>
> ¿Y cuál es el problema que te señaló?
>
>

Fueron varios los problemas que se detectaron, desde una cuenta de
dba_auxilitar común:

1. Los dba_auxilitar tenian acceso como super usuario
R. Se quitaron todos los privilegios de superusuarios a los
dba_auxilitares

2. El servidor Web almacenaba en en un script una contraseña genérica
de superusuario para todos los accesos del sistema a la base de datos

R. Se reestructuro el mecanismo de autentificación para que todo
usuario de sistema web tenga un usuario de base de datos
con su contraseña doblemente encriptada md5(md5(contraseña)). Por que
existen varios roles propios del sistema, la dificultad de
administración, y premura
el estos nuevos usuarios de base de datos tenían privilegios de
superusuario

3. El testeador accede a la tabla de usuario donde esta almacenada la
contraseña con un MD5, descbure que el mecanismo de
autentificación de usuarios en sistema es doble
MD5(MD5(contraeña)) y accede a la base de datos

R. No puedo ocultar la tabla de usuarios ya que todas los procedimientos
almacenados acceden a la tabla para valida privilegios del rol de sistema.
El sistema hace su propio control de privilegios pero solo es para
los accesos a travez del mismo a esto le llamo roles de sistema.
Tampoco puedo ocultar el acceso a las función que tiene el
mecanismo de encriptación, (trate pero no puede),
Entonces se me ocurre concatenar las contraseñas con la palabra
secreta MD5(semilla || MD5 (contraeña)),
que tampoco es útil porque la palabra tiene que estar almacena en
una función y todos pueden ver la estructura de las funciones por que es
PUBLIC.
Entonces ustedes me dan la idea de utilizar semilla aleatoria
almacenada en otra tabla a la que si puedo quitarle los permisos

Adicionalmente también le quite los privilegios de superusuario a los
usuarios de sistema y cree un rol de base de datos con privilegios
sobre todos los esquemas y tablas (SELEC, INSERT DELETE, UPDATE) pero
limitado para crear estructuras y todo los demás.....

La lista vulnerabilidades puede seguir creciendo y el problema es que se
tiene que tratar de pensar en todo para que el sistema sea mas seguro
pero nunca se ve llegar aun sistema 100 seguro.
Ademas todos estos problemas debieron ser considerados a momento de
diseñar donde era menos costoso realizar cambios

saludos

--
EMPRESA NACIONAL DE ELECTRICIDAD
www.ende.bo
Tel.: (591-4) 4520253 - 4520228
Fax: (591-4) 4520318
---------------------------------------------------------------------------------
Este mensaje ha sido analizado automaticamente por el MailScanner de ENDE
y no han sido detectados virus ni otros contenidos peligrosos.

Rensi Arteaga Copari escribió:

> R. Se reestructuro el mecanismo de autentificación para que todo
> usuario de sistema web tenga un usuario de base de datos
> con su contraseña doblemente encriptada md5(md5(contraseña)). Por
> que existen varios roles propios del sistema, la dificultad de
> administración, y premura
> el estos nuevos usuarios de base de datos tenían privilegios de
> superusuario

Huh. Creo que aquí partió tu problema. md5 no es una función de
cifrado (lo que tú mal llamas encriptación); es una función de
"digerido". Usarla como si fuera cifrado es una idea muy mala, porque
es obvio cómo encontrar una manera de escapársele.

> 3. El testeador accede a la tabla de usuario donde esta almacenada
> la contraseña con un MD5, descbure que el mecanismo de
> autentificación de usuarios en sistema es doble
> MD5(MD5(contraeña)) y accede a la base de datos

Este es obviamente otro problema muy serio (o, mejor dicho, es el mismo
problema de arriba). La contraseña del usuario debes almacenarla pasada
por md5(), y lo que te envía el usuario al conectarse debes aplicarle el
mismo digerido md5() una sola vez. Hacerlo doble te somete al estúpido
problema de que alguien puede ver el md5 en tus tablas y aplicar md5 una
vez para conectarse a la base de datos.

Esconder los digeridos es sencillo pero no soluciona el problema de
fondo.

> R. No puedo ocultar la tabla de usuarios ya que todas los
> procedimientos almacenados acceden a la tabla para valida
> privilegios del rol de sistema.

No es necesario ocultarla.

> La lista vulnerabilidades puede seguir creciendo y el problema es
> que se tiene que tratar de pensar en todo para que el sistema sea
> mas seguro
> pero nunca se ve llegar aun sistema 100 seguro.

Nunca va a llegar a ser 100% seguro, pero debes evitar los errores tontos.

--
Alvaro Herrera Developer, http://www.PostgreSQL.org/
"Most hackers will be perfectly comfortable conceptualizing users as entropy
sources, so let's move on." (Nathaniel Smith)

El 07/04/10 17:21, Alvaro Herrera escribió:
>> R. Se reestructuro el mecanismo de autentificación para que todo
>> > usuario de sistema web tenga un usuario de base de datos
>> > con su contraseña doblemente encriptada md5(md5(contraseña)). Por
>> > que existen varios roles propios del sistema, la dificultad de
>> > administración, y premura
>> > y estos nuevos usuarios de base de datos tenían privilegios de
>> > superusuario
>>
> Huh. Creo que aquí partió tu problema. md5 no es una función de
> cifrado (lo que tú mal llamas encriptación); es una función de
> "digerido". Usarla como si fuera cifrado es una idea muy mala, porque
> es obvio cómo encontrar una manera de escapársele.
>
>
>> > 3. El testeador accede a la tabla de usuario donde esta almacenada
>> > la contraseña con un MD5, descbure que el mecanismo de
>> > autentificación de usuarios en sistema es doble
>> > MD5(MD5(contraeña)) y accede a la base de datos
>>
> Este es obviamente otro problema muy serio (o, mejor dicho, es el mismo
> problema de arriba). La contraseña del usuario debes almacenarla pasada
> por md5(), y lo que te envía el usuario al conectarse debes aplicarle el
> mismo digerido md5() una sola vez. Hacerlo doble te somete al estúpido
> problema de que alguien puede ver el md5 en tus tablas y aplicar md5 una
> vez para conectarse a la base de datos.
>

Con repecto al MD5, es solo un problema de expresión, se que MD5 es
una función de digestión de una sola vía
( MD5(texto_claro) = texo_digerido, después que el texto esta digerido
con esta función, a partir del texto_digerido no puedes optener el
texto_claro)
y MD5 esto es lo que necesito para almacenar la contraeña_digerida en la
tabla de usuarios. y no, por decir un ejemplo, DES o AES

El problema es que se quiere parchar un sistema que no fue diseño
pensando en seguridad, es claro que la mejor solución es la que sugieres.
Pero ahora se tiene 200 usuarios de sistema con sus contraseñas ya
registradas (antes de ser detectado el problema),
y para hacer los que dices debería conocer la contraseña en texto_claro,
o cambiar y reasignar todas las contraseña a todos los usuarios;
pero esto ultimo no lo puedo hacer, por política del gerente de TI los
usuarios no pueden cambiar de contraseña, ni siquiera ellos mismos. y
una orden es una orden

Y eso es el mayor problema convencer a los altos mando de la
importancia de la seguridad.

--
EMPRESA NACIONAL DE ELECTRICIDAD
www.ende.bo
Tel.: (591-4) 4520253 - 4520228
Fax: (591-4) 4520318
---------------------------------------------------------------------------------
Este mensaje ha sido analizado automaticamente por el MailScanner de ENDE
y no han sido detectados virus ni otros contenidos peligrosos.

Rensi Arteaga Copari escribió:

> Pero ahora se tiene 200 usuarios de sistema con sus contraseñas ya
> registradas (antes de ser detectado el problema),
> y para hacer los que dices debería conocer la contraseña en
> texto_claro, o cambiar y reasignar todas las contraseña a todos
> los usuarios;
> pero esto ultimo no lo puedo hacer, por política del gerente de TI
> los usuarios no pueden cambiar de contraseña, ni siquiera ellos
> mismos. y una orden es una orden

200 usuarios no son nada. Obligar a todo el mundo a cambiar de
contraseña no es tan difícil.

Ahora, políticas idiotas son políticas idiotas ... te aconsejo conseguir
esa política en un papel firmado por el gerente en cuestión, y lo tienes
bien guardado lejos de él, para que no te echen la culpa a ti más tarde.

--
Alvaro Herrera Developer, http://www.PostgreSQL.org/
"Porque Kim no hacía nada, pero, eso sí,
con extraordinario éxito" ("Kim", Kipling)

2010/4/7 Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>:
[...]
>> por política del gerente de TI
>> los usuarios no pueden cambiar de contraseña, ni siquiera ellos
>> mismos. y una orden es una orden
>
[...]
>
> Ahora, políticas idiotas son políticas idiotas ... te aconsejo conseguir
> esa política en un papel firmado por el gerente en cuestión, y lo tienes
> bien guardado lejos de él, para que no te echen la culpa a ti más tarde.
>

no habra algun premio que le podamos otorgar a este gerente? nunca
habia escuchado semejante tonteria...

--
Atentamente,
Jaime Casanova
Soporte y capacitación de PostgreSQL
Asesoría y desarrollo de sistemas
Guayaquil - Ecuador
Cel. +59387171157

El 07/04/10 18:13, Alvaro Herrera escribió:
> Ahora, políticas idiotas son políticas idiotas ... te aconsejo conseguir
> esa política en un papel firmado por el gerente en cuestión, y lo tienes
> bien guardado lejos de él, para que no te echen la culpa a ti más tarde.
>
Tienes todas la razón voy a conseguir el respaldo que mencionas, de
alguna u otro forma
Espero no levantar mas polémica al respecto

muchas gracias por tu ayuda

saludos

rensi

--
EMPRESA NACIONAL DE ELECTRICIDAD
www.ende.bo
Tel.: (591-4) 4520253 - 4520228
Fax: (591-4) 4520318
---------------------------------------------------------------------------------
Este mensaje ha sido analizado automaticamente por el MailScanner de ENDE
y no han sido detectados virus ni otros contenidos peligrosos.