si a un sistema con una buena seguridad le añades un poco de oscuridad, la cosa puede mejorar.
Efectivamente. Cuanto más oscuridad le des a los ojos que no administrarán la máquina, mejor. A más dificultemos para la manipulación por parte de terceros, infinitamente mejor. 100% de acuerdo
La clave es cuando menciona el kernel de GNU/Linux, diciendo que los otros programas no estan tan trabajados. Normal. Es que no se pueden comparar versiones hechas por aficionados a la programación en un poco de tiempo libre o sin acabar con programas profesionales en los que ha trabajado un equipo con experiencia durante un buen tiempo.
La cosa esta en que si quiere comparar PROYECTOS de código abierto, que los compare con PROYECTOS de código cerrado (es decir, comparar programas sin acabar y sin tiempo de rodaje con sus iguales del software). Y no se yo como va a compararlos cuando no puede acceder al código de estos últimos... Ni creo que las empresas que hacen código cerrado le permitan al autor del estudio ver sus versiones más preliminares.
Creo que los fallos seguro que estan igual que en el código abierto solo que estos solo se conocen cuando ya han tenido problemas con ellos los usuarios. Pero entonces, a veces es demasiado tarde, porque puede resultar que el fallo solo haya sido descubierto por una persona malintencionada que lo haya buscado a drede. Y que esto le de un tiempo extra para desarrollar virus, cracks o lo que quiera/pueda hasta que los propietarios del código vean el error.
Como ejemplo, la historía de Windows y sus fallos graves de seguridad y como muchas veces no era la gente de Redmond la que los descubria.
La seguridad por la oscuridad no tiene porque ser seguridad pero si a un sistema con una buena seguridad le añades un poco de oscuridad, la cosa puede mejorar.
Estoy en desacuerdo. Como desarrollador, si cuentas con la "seguridad por oscuridad", aunque quieras hacer tu código seguro incoscientemente es posible que lo desarrolles "menos seguro", contando que el añadido de la "oscuridad" hará tu código seguro.
Es como si desarrollas algún sistema de red, y como cuentas con que esté protegido por un firewall, cuando se acerque el dia de entrega y tengas que apurar, es probable que acabes diciendo cosas como "bueno, no tengo porque poner codigo para controlar las IPs desde las que acceden, total, si va a estar protegido por un firewall; ya lo haré otro dia más adelante". Lo más normal es que ese dia tarde mucho en llegar (o no llegue), y si por lo que sea falla el firewall, te quedas en bragas.
Lo mejor para desarrollar cosas seguras es suponer que no hay ABSOLUTAMENTE nada que protega tu programa de los demás, que te lo tienes que currar tu todo. Para la seguridad, supón que TODO el mundo va a recibir una copia del esquema de los sistemas seguros que has programado.
1 respuesta por debajo de tu umbral de lectura actual.
Oscuridad a quien no tenga nada que ver
(Puntos:2)( http://www.sahw.com/wp | Última bitácora: Lunes, 16 Febrero de 2009, 09:13h )
Efectivamente. Cuanto más oscuridad le des a los ojos que no administrarán la máquina, mejor. A más dificultemos para la manipulación por parte de terceros, infinitamente mejor. 100% de acuerdo
Un saludo ;)
Sergio Hernando [sahw.com] - In security we trust
No estoy de acuerdo
(Puntos:1)( Última bitácora: Domingo, 15 Junio de 2008, 05:41h )
La cosa esta en que si quiere comparar PROYECTOS de código abierto, que los compare con PROYECTOS de código cerrado (es decir, comparar programas sin acabar y sin tiempo de rodaje con sus iguales del software).
Y no se yo como va a compararlos cuando no puede acceder al código de estos últimos... Ni creo que las empresas que hacen código cerrado le permitan al autor del estudio ver sus versiones más preliminares.
Creo que los fallos seguro que estan igual que en el código abierto solo que estos solo se conocen cuando ya han tenido problemas con ellos los usuarios.
Pero entonces, a veces es demasiado tarde, porque puede resultar que el fallo solo haya sido descubierto por una persona malintencionada que lo haya buscado a drede. Y que esto le de un tiempo extra para desarrollar virus, cracks o lo que quiera/pueda hasta que los propietarios del código vean el error.
Como ejemplo, la historía de Windows y sus fallos graves de seguridad y como muchas veces no era la gente de Redmond la que los descubria.
Falsa sensación de seguridad
(Puntos:1)( http://www.barrapunto.com/ )
Estoy en desacuerdo. Como desarrollador, si cuentas con la "seguridad por oscuridad", aunque quieras hacer tu código seguro incoscientemente es posible que lo desarrolles "menos seguro", contando que el añadido de la "oscuridad" hará tu código seguro.
Es como si desarrollas algún sistema de red, y como cuentas con que esté protegido por un firewall, cuando se acerque el dia de entrega y tengas que apurar, es probable que acabes diciendo cosas como "bueno, no tengo porque poner codigo para controlar las IPs desde las que acceden, total, si va a estar protegido por un firewall; ya lo haré otro dia más adelante". Lo más normal es que ese dia tarde mucho en llegar (o no llegue), y si por lo que sea falla el firewall, te quedas en bragas.
Lo mejor para desarrollar cosas seguras es suponer que no hay ABSOLUTAMENTE nada que protega tu programa de los demás, que te lo tienes que currar tu todo. Para la seguridad, supón que TODO el mundo va a recibir una copia del esquema de los sistemas seguros que has programado.