Recientemente he escuchado que la mayoría del código PHP es confidencial, porque si los atacantes conocen la estructura de su base de datos o la función hash utilizada para cifrar las contraseñas, hay mayores posibilidades de una violación.
Me preguntaba, si es así, ¿qué pasa con los proyectos de código abierto en los que todo está a la vista?
Recientemente he escuchado que la mayoría del código PHP es confidencial, porque si los atacantes conocen la estructura de su base de datos o la función hash utilizada para cifrar las contraseñas, hay mayores posibilidades de una violación.
Eso es solo cuando los diseñadores no usan la función hash correcta o protegen la aplicación web de la inyección de SQL. Pero estas cosas se pueden detectar fácilmente, en la actualidad hay herramientas automatizadas que pueden buscar vulnerabilidades de inyección de SQL a través del código fuente (en lugar de señalar sqlmap en la aplicación web)
Si usa algo como scrypt, está perfectamente seguro de decirle a todos que lo usa.
MediaWiki solía usar un hash MD5 con sal. El salt es específico de la instalación y no forma parte del código fuente abierto (se genera en la instalación). Esto no es tan seguro como podría serlo (las sales por usuario y el uso de un mejor algoritmo de hash serían mejores), pero sigue siendo seguro siempre que el archivo LocalSettings no esté expuesto. (Es cierto que eso no es un gran nivel de seguridad). Creo que Drupal también hace esto , pero con sha512.
Me preguntaba, si es así, ¿qué pasa con los proyectos de código abierto en los que todo está a la vista?
La seguridad por oscuridad no es seguridad. Si poner el código a la intemperie afecta la seguridad, en primer lugar no tiene ninguna seguridad.
Además, si hay agujeros de seguridad en el código, estos también pueden ser atrapados por los contribuyentes. Recientemente detecté y reparé un error relacionado con la seguridad en el software Bugzilla, por ejemplo.
Esto se llama " security through obscurity ", que generalmente se considera un mal modelo de seguridad para la mayoría (si no todos los propósitos.
Hay dos términos principales que se centran en este concepto:
Un criptosistema debe ser seguro, incluso si todo sobre el sistema, excepto la clave, es de conocimiento público.
Claude Shannon lo reformuló más tarde, en términos más genéricos, como la máxima de Shannon :
El enemigo conoce el sistema.
El punto es que la seguridad debe provenir de conceptos de seguridad sólidos, en lugar de tratar de ocultar información y algoritmos. Las operaciones criptográficas sólidas garantizan la seguridad, mientras que el código privado solo garantiza la oscuridad.
Recientemente he oído que la mayoría del código PHP es confidencial
Esto parece ser incorrecto. Al momento de la concesión, la mayoría de PHP está libre de errores y es legible para cualquier persona a la que se le distribuya.
porque si los atacantes conocen la estructura de su base de datos o la función hash utilizada para cifrar las contraseñas, hay mayores posibilidades de una violación.
También incorrecto. Ni la estructura de la base de datos, ninguna función hash es crítica en la arquitectura de la violación inicial. Pueden ser útiles después de una infracción, pero lo importante para generar el ataque inicial es el conocimiento de alguna falla o vulnerabilidad en el código del sitio.
Tener el código fuente puede ser útil para encontrar vulnerabilidades de seguridad (cf. Wordpress y los complementos de Joomla), no es realmente necesario. De hecho, la mayoría de las vulnerabilidades interesantes (Windows, Flash, Internet Explorer, Acrobat, etc.) se encuentran sin la ayuda del código fuente.
Hacer que su proyecto sea de Código Abierto hace que el código sea más fácil para que terceros lo auditen (con o sin su permiso) que debería conducir a un descubrimiento anterior de errores y vulnerabilidades, con la esperanza de que sean más rápidos y fáciles de parchar .
Suponiendo que su proyecto es lo suficientemente popular como para obtener una cantidad razonable de escrutinio, esto debería significar que es menos probable que su proyecto tenga vulnerabilidades de seguridad importantes una vez que se complete el período inicial de detección y revisión. Es difícil obtener buena información sobre esto, pero algunas pruebas sugieren que el software de código abierto popular tiene menos probabilidades de tener esas vulnerabilidades "durmientes" que están presentes y activas pero no publicadas durante décadas.
Lea otras preguntas en las etiquetas opensource