Hola. El Jueves, 8 de Marzo de 2007, miguel gmail escribió:
en la compania donde trabajo estamos probando un software disenado para los fideicomisos (no me pregunten que es un fideicomiso) desarrollado por un contratista bajo php/mysql
Buff.
Yo no usaría php para nada serio.
Por que, hay mucha cosa "seria" hecha en php
estaba revisando por encima el codigo y me encontre que cuando la aplicacion es llamada esta carga una pagina que contiene la direccion del servidor de base de datos, el nombre de la base de datos y el usuario y password que utilizaria en la conexion en texto claro y legible
Normal.
No, no es normal, se puede hacer de muchas maneras, por ejemplo con una hash en MD5 o SHA o SMD5 o Crypt o ........ Mira cualquier aplicacion php conocida por ejemplo phpldapadmin, phpmyadmin, eGroupware, etc
por supuesto para poder leer este archivo hace falta ser el usuario que maneja el apache o estar en el grupo del apache, pero sin embargo como la aplicacion no utiliza ningun tipo de ssl para realizar sus conexiones, me parece un poco "ligero" tener esta informacion sin ningun tipo de encripcion.
Si, yo veria la opcion de ponerla con un hash.
me gustaria saber si hay alguien que haya trabajado con php/mysql, como hace con estos casos en los que es necesario encriptar un password / usuario, etc, dentro de la aplicacion pero sin dejar que la aplicacion pueda leer esta informacion tan necesaria.
Como dije arriba
Varias cosas:
- usar ssl. Si hay que enviar usuario y pwd, mejor que sea encriptado. Pero el cliente podrá verlo si es un poco hábil.
Tampoco hay que ser paranoico. Esta aplicacion es para un banco? esta en una industria que necesita mucha inversion en i+d? (farmaceutica, quimica, aeronautica, automocion) es probable que alguien invierta horas en descifrar un acceso https ( que puede ser con certificado emitido por ti para permitir el acceso) y posteriormente romper un SMD5?
- usar otra arquitectura: presentación - capa de negocio - bbdd. NO sé si php soporta algo así, pero J2EE nació para esto.
si que soporta eso, para eso es LAMP
El que tomó la decisión de hacerlo en LAMP (presumo que LAMP) tendrá que hacerse responsable de los 'bujeros' de seguridad que deja php (muchos) y los desarrolladores de php (aún más).
???
Por cierto que, no se si febrero o marzo ha sido el mes en que php has sido declarado proyecto del mes para securizarlo. Se trata de encontrar el mayor número de bugs posibles durante un mes para dejarlo lo más seguro posible.
Esto es una practica muy habitual en aplicaciones opensource, en kde lo estan haciendo con frecuencia cada vez sobre una aplicacion. El que para otras aplicaciones no se haga, no quiere decir que sean mas seguras. -- Un Saludo. Carlos Lorenzo Matés