Con lo que sabemos hoy en día parece que es prácticamente imposible entregar un producto informático sin fallos (aunque hay quien dice que puede hacerlo bastante bien), System complexity, safety, security drive continued adoption of Ada, SPARK in aerospace and defense software engineering).

También nos gusta bastante la cantidad de cosas que se pueden aprender de los productos de código abierto, donde se puede mirar, medir y aprender (Bitergia, por ejemplo, se dedica a eso).

Podíamos leer en Static analysis on the Linux kernel los resultados de diferentes mediciones realizadas sobre el kernel de Linux, principalmente los análisis que realiza la empresa Coverity sobre diversos proyectos de software libre. El resumen sería este:

As one can see, there are a lot of defects getting fixed by the Linux developers and the overall trend of outstanding issues is downwards, which is good to see. The defect rate in linux-next is currently 0.46 issues per 1000 lines (out of over 13 million lines that are being scanned). A typical defect rate for a project this size is 0.5 issues per 1000 lines. Some of these issues are false positives or very minor / insignificant issues that will not cause any run time issues at all, so don’t be too alarmed by the statistics

Esto es, en el Kernel de Linux tiene una tasa de defectos de 0.46 por cada mil líneas, teniendo en cuenta que es una prueba automatizada que detectará como fallos cosas que no lo son, y dejará de detectar otros.

Llevamos una temporada escuchando que la autentificación con dos factores es la solución para los problemas de las malas contraseñas que eligen los usuarios y otros problemas de la autentificación mediante contraseña. La autentificación de dos factores se vió puesta en entredicho este verano por la inseguridad de los SMS Reddit hack highlights vulnerability of two-factor authentication. No obstante, podemos ver en Inside Two-Factor Authentication Apps proporcionan algunas pistas interesantes y una introducción al tema que podemos leer, con ejemplos de código en Python.

So I’m going to step quickly through how 2FA apps work, and then show you how you can implement it yourself if you want in a few lines of Python.

Para hacer una autentificación de dos factores, en la práctica, muchcas aplicaciones utilizan para generar el segundo factor el algoritmo de clave de un solo uso basado en tiempo:

In practice, because of cost and convenience, most 2FA implementations use an app that authenticates using the time-based one-time password (TOTP) algorithm. That is, it’s just another password.

Se basan en una contraseña secreta, un secreto compartido (el momento de la petición) y una función de hash:

The beauty of these algorithms is that the one-time secret password is hashed with some other number that’s common knowledge to me and the server — sometimes it’s a simple counter. This generates a different “password” for every value of the counter.

Para no tener problemas con las diferencias de tiempo entre el cliente y el servidor hace falta un pequeño ajuste, que consiste en habilitar tramos de alrededor de 30 segundos y, además, dar por bueno el anterior y el posterior:

In most TOTP implementations, the counter is the number of 30 second intervals that have elapsed since Jan 1, 1970 — the Unix epoch. This gives you a different, strong, password every 30 seconds. Practically, servers will accept either the previous, current, or next values to allow for clocks to go a little out of sync, but after a minute or so, that old hashed value is useless to an attacker. That’s pretty cool

Interesante.

El sistema de autentificación de los usuarios sigue siendo la única puerta de entrada a las caraterísticas de nuestro sistema que podamos ofrecerles. Por este motivo, es una fuente segura de ataques, con diversas formas de intentar atacarnos para ver qué se puede conseguir.

En 4 Ways to Secure Your Authentication System in Rails hablan del tema para aplicaciones desarrolladas en Ruby on Rails, aunque las ideas se pueden aplicar en otros contextos.

Los consejos:

• Restringir las peticiones. Esto es, tratar de evitar los ataques de fuerza bruta, donde el ‘malo’ simplemente va probando diferentes identificadores y credenciales.

• Poner las cabeceras de seguridad correctamente. Estar al día en las novedades y modificar nuestras aplicaciones no es un asunto trivial, pero tampoco es normal no aprovechar de las ventajas de unas cabeceras adecuadas (Recordatorio: El uso de las cabeceras de los sitios web populares para aprender de seguridad).

• Leer bibliotecas de autentificación. Leer el código de otros proyectos puede ayudarnos a hacer mejor las cosas nosotros. También el registro de cambios changelog Da como ejemplo algunas características de algunas bibliotecas de las que se pueden aprender cosas interesanets (almacenamiento de hash de contraseñas separados y otros).

• Asegurar el resto de la aplicación. Claro. Da igual tener el mejor sistema de autentificación si pueden entrar por otro sitio.

Ya hace años que es una queja frecuente en el mundillo de la seguridad: cuando te enseñan a programar, no sólo no te enseñan seguridad sino que los ejemplos que te muestran son en muchos casos una muestra de lo que no debe hacerse si te preocupa la seguridad.

Ya pasaba en los libros pero ahora hay un estudio sobre el mismo tema con los ejemplos en foros bien reconocidos de programadores. Nos lo contaban en Try Catch Stack Overflow y hablan de un estudio ([PDF] Secure Coding Practices in Java: Challenges and Vulnerabilities) donde han analizado la calidad del código que podemos encontrar en el conocido sitio StackOverflow y otros similares donde se reproduce el mismo patrón. Algunas respuestas populares y bien calificadas contienen vulnerabilidades desde el punto de vista de la seguridad.

Basado en el estudio sobre las preguntas y respuestas dadas en torno al lenguaje y plataforma Java, los investigadores han encontrado multitud de errores en respuestas populares que contienen vulnerabilidades de seguridad. El problema, señalan, no se encuentra en las librerías usadas –que no deja de ser reutilización legítima de código-, sino en que estas no se usan de forma segura, dando lugar a la exposición de riesgo por falta de pericia en su uso.

Naturalmente, no es una crítica al sitio, que es un recurso maravilloso cuando uno no sabe muy bien cómo avanzar. Pero debemos mantener el espíritu crítico y no seguir los consejos ciegamente, porque tendremos problemas.

Por el motivo que sea, todos creemos que podemos esconder algo de manera más o menos eficaz en un sistema informático: bien porque creemos que no es tan importante y nadie lo buscará, bien porque pensamos que los que lo buscarán no son tan listos como para seguir nuestra línea de pensamieno. A veces también porque no nos damos cuenta de lo que tiene que ser (o directamente es) secreto. Y, claro, nos equivocamos.

Por eso es interesante leer Secrets Management: New Series. La serie se compone de tres capítulos:

• Secrets Management: Use Cases

Aquí se hace una panorámica por los accesos a diferentes APIs y la gestión de claves de acceso, los servicios automáticos, la automatización en el desarrollo (compilación, prueba, …), los datos cifrados y la información compartida.

• Secrets Management: Features and Function

Aquí se habla del almacenamiento de los secretos, la gestión de identidad y de accesos, los propios acceso y el uso y nuevamente la información compartida (en este caso, los propios secretos).

• Secrets Management: Deployment Considerations

En el despliegue, hay que tener en cuenta si hablamos de servidores aislados, o arquitecturas cliente-servidor y, por supuesto, los temas de integración.