¿Debe reutilizarse o reescribirse el código crítico para la seguridad?

Lo importante es mantenimiento . Independientemente de si reutilizó el código existente o escribió el suyo, logrará una seguridad decente solo si hay alguien, en algún lugar, que entienda el código y pueda mantenerlo a flote con respecto a, digamos, la evolución de compiladores y plataformas. Tener código sin errores es lo mejor, pero en la práctica debe confiar en la siguiente mejor opción, es decir, la solución rápida de errores (especialmente los errores que pueden aprovecharse para uso malicioso, también conocido como vulnerabilidades ), dentro de un corto período de tiempo.

Si escribe su propio código, entonces el trabajo de mantenimiento se basa totalmente en sus propios hombros. Y ese trabajo puede llevar mucho tiempo. Por ejemplo, si decide escribir y mantener su propia biblioteca SSL / TLS, y la utiliza en producción, debe comprender todas las peculiaridades de la implementación criptográfica, en particular la resistencia a ataques de canal lateral , y debes estar atento a los ataques y contramedidas publicados. Si tiene los recursos para eso, tanto en tiempo como en competencia, ¡entonces bien! Pero el costo de mantenimiento no debe ser subestimado. Reutilizar una biblioteca existente, especialmente una de código abierto que se usa ampliamente, puede ser bastante más barato a largo plazo, ya que el mantenimiento es realizado por otras personas y el uso generalizado garantiza un control externo. Como beneficio adicional, no se puede culpar por los agujeros de seguridad en una biblioteca externa si la mitad del mundo los comparte.

Para resumir, la pregunta no es realmente sobre la reutilización de código , sino sobre la reutilización de mantenimiento .

(Escribo todo esto independientemente de las grandes cualidades pedagógicas de escribir tu propio código. Te animo a que hagas tus propias implementaciones, pero ciertamente no para usarlas realmente en producción. Esto es para aprender .)

Más aún.

El código de seguridad es complicado . El código de criptografía es francamente difícil , incluso si usted es un criptógrafo capacitado, e imposible de hacerlo si no lo es.

Si hay tantos errores críticos en tantos paquetes de software y compañías tan importantes, ¿qué te hace pensar * que podrías hacer un mejor trabajo?

_{* A menos que, por supuesto, este sea su dominio específico de experiencia, y la funcionalidad de seguridad sea fundamental para su producto ...}

Pregunta interesante! Me gustaría responderlo más desde el punto de vista de probabilidad, que desde el punto de vista de Mejores prácticas actuales.

Si bien Thomas y otros brindan excelentes respuestas, no creo que toquen la pregunta central, que es "es un código único (o menos usado) más resistente en la práctica que el código popular". Tenga en cuenta que deliberadamente no he usado "más seguro que el código popular". ¿Y a qué se reduce eso es el caso especial de "la seguridad a través de la oscuridad funciona"?

Y (y sé que esta no va a ser una respuesta popular) Creo que cuando reemplazamos "seguro" por "resiliente", es posible que la respuesta no siempre sea comúnmente aceptada "¡nunca!"

Es probable que sea menos seguro (lo que significa que es muy probable que su propio código de seguridad sea más fácil / más rápido de descifrar que el popular, que ya había sufrido muchos ataques antes y fue corregido por personas más inteligentes que tú).

Sin embargo, a menos que usted sea un sitio grande / popular, también se destaca que es mucho menos interesante para los posibles crackers si no pueden reutilizar el código / esfuerzo empleado en descifrarlo, y ese esfuerzo no es -trivial (lo que significa que su sitio no se descompondrá en la no validación del parámetro automatizado / sondas de inyección de SQL). Obviamente, esto no funciona si está dirigido específicamente (espionaje industrial, etc.), pero la gran mayoría de los ataques en esos días parecen ser sondas automatizadas para software popular.

Entonces, si la pregunta no es "cuál es más segura", sino "que es menos probable que se resuelva", la respuesta podría ser "depende". Aquí hay algunos ejemplos:

Ejemplo 1: Imagine una computadora con Microsoft Windows 8.1 (o lo que es popular en estos días), actualmente sin agujeros de seguridad conocidos, comprados pero nunca actualizados, conectados a Internet. También imagine décadas de Windows 3.11 con winsock, nunca parchadas, con cientos de agujeros de seguridad conocidos, conectados a Internet. Ambos se utilizan de la misma manera. Ignorar con el propósito de discutir la calidad del acceso ... La pregunta es, ¿cuál será interrumpida antes?

Si bien es obvio que 3.11 es mucho menos seguro, casi no hay ninguna vulnerabilidad en la naturaleza que lo apunte. Por lo tanto, bien podría ser que hubiera un exploit masivamente popular de 0 días para que 8.1 lo golpeara, antes de que el 3.11 alcance un exploit arcaico que se ejecute en él.

Ejemplo 2: imagina que tienes el último CMS de Joomla en un servidor web sin explotaciones actuales conocidas, y un script perl hecho a mano que hace cosas de CMS, con errores explotables conocidos (pero ninguno de ellos sospechoso de pruebas automatizadas actualmente disponibles). Después de un año, ¿cuál tiene mayores posibilidades de ser explotado?

Aunque hay evidencia anecdótica, en pocas docenas (a cientos) de casos que he tenido en décadas pasadas, fue en la mayoría de los casos que se explotó el software popular, mientras que los obsoletos continúan funcionando hasta el día de hoy sin problemas.

Otras cosas que vale la pena considerar:

• si el software popular se actualiza automáticamente (o tiene administradores SIEMPRE actualizándolo rápidamente), entonces las debilidades de dicho código popular se reducen mucho (pero no se eliminan, debido a vulnerabilidades de 0 días y no publicadas) y, por lo tanto, tienen una gran ventaja
• a la inversa, si el software no va a recibir mantenimiento, uno no popular (como uno mismo) es realmente menos sospechoso de problemas
• culpa: a menudo puede ser ventajoso usar software popular. Si la mitad del mundo está afectada, no tendrás tanta culpa como si fueras un programador único. Esto es especialmente importante si se trabaja con dinero. A menudo es "mejor" estar menos seguro pero ser capaz de cambiar la culpa, que estar más seguro pero tener que pagar el costo cuando el exploit golpea.
• trabajo: ya mencionado por otros, el software popular en la mayoría de los casos se solucionará solo, solo necesita actualizarlo, que es mucho menos trabajo que encontrarlo y corregir errores (pero aún requiere algunos mantenimiento)
• otra ventaja para el software de auto-escritura es a menudo la reducción de código masivo (lo que lleva a menos errores), ya que generalmente no necesita la mayoría de las funciones o personalización. Por ejemplo, la gente usará Joomla incluso si todo lo que necesitan es un simple "sitio de noticias de plantilla" que en la práctica podría lograrse con pocas docenas de líneas de código. Incluso si usted como programador no es la mitad de bueno que los que trabajan en un software popular (por lo que tiene un número notablemente mayor de errores por línea de código), a menudo aún puede ganar por un gran margen debido a su orden de magnitud ( o pocos!) menos código para escribir / mantener

La respuesta simple es: no ruedes tu propia seguridad.

Hay dos partes en esto. Algoritmo e implementación.

En cuanto al algoritmo, crear tu propio algoritmo de cifrado es terrible. Incluso si está versado en el campo de la criptografía, todavía no está en condiciones de crear un nuevo algoritmo. A menos que tenga un equipo de expertos en el campo trabajando en ello, no puede utilizar su propio algoritmo. Para llevar a casa este punto, observe algunos de los algoritmos recientes que se han descifrado y cómo se descifraron. Lo que se ve bien en el valor nominal tiene debilidades que nunca hubiera concebido.

En cuanto a la implementación, crear tu propia implementación de un buen algoritmo no es tan horrible como crear tu propio algoritmo, pero a menos que seas un profesional en eso, no lo hagas. Un error en la implementación y no importará cuán bueno sea el algoritmo central. En este caso, la pregunta que debe hacer es si es mejor que los muchos expertos que trabajaron para armar una biblioteca de seguridad de primera línea.

Lo que es más probable. ¿Que puede hacer rodar su propio algoritmo e implementación sin ningún error o debilidad, o que el algoritmo y la implementación que usa van a tener una puerta trasera instalada?

Si pudiera crear un algoritmo perfecto con implementación, el riesgo de la puerta trasera no sería un problema. Pero eso no es realista.

También está la pregunta sobre la cual desea explicárselo a su gerente / accionistas / ect. Que se colocó una puerta trasera en un paquete de software confiable de alta calidad que tiene a toda la industria funcionando o que su intento personal de mejorar la seguridad fracasó horriblemente. Personalmente, me gustaría mucho más explicar que tomé la decisión que tomaron los profesionales de toda la industria y la única razón por la que falló fue un problema de nivel masivo que está afectando incluso a las empresas multinacionales.

Dicho esto, estoy de acuerdo con Thomas en que intentar hacerlo tú mismo es una buena experiencia de aprendizaje siempre y cuando nunca veas la luz de la producción.

La seguridad no se mejora necesariamente simplemente si el código se compila con instrucciones ligeramente diferentes. La seguridad es:

1. algoritmo
2. Implementación
3. Auditoría
4. Mantenimiento

Si no está escribiendo algoritmos mejores y más seguros, lo que puede llevar años de investigación, y no se audita su código, y los parches correspondientes, entonces es muy poco probable que una implementación ligeramente diferente lo haga seguro. / p>

Se han producido problemas de Heartbleed, Shellshock, BEAST, POODLE y otros varios problemas importantes de SSL / TLS debido a problemas inherentes a los algoritmos CRC y autoreferenciales, y la falta de auditorías de código experimentadas, no Debido a la implementación.

Si realmente no entiende cómo fallaron, definitivamente no debe escribir su propio código de seguridad. Añadirás más problemas de los que resolverás.