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.
--
TIP 9: visita nuestro canal de IRC #postgresql-es en irc.freenode.net
