La liga de la entropía y la aleatoriedad

Dados En The League of Entropy Is Making Randomness Truly Random un texto interesante sobre aleatoriedad y ordenadores, así como algunos proyectos que ofrecen números aleatorios ‘de verdad’.

Entre otros, hablan de League of Entropy que se trata de un proyecto colaborativo.

Como nos cuentan en League of Entropy: Not All Heroes Wear Capes, proporcionan números aleatorios no predecibles en intevalos regulares.

A randomness beacon is a public service that provides unpredictable random numbers at regular intervals.

Al tratarse de números que son públicos, hay usos para los que se pueden contemplar (un sorteo, por ejemplo, donde es importante la auditabilidad y la transparencia) pero no para otros (una clave, donde el secreto es importante).

Modelado de amenazas y argumentos a su favor

Mirada amenazante Cuando nos preocupa la seguridad informática tenemos que tener claro cuáles son los riesgos que nos afectan. Para ello se puede utilizar el modelado de amenazas (threat modelling) y en Three Killer Arguments for Adopting Threat Modeling nos daban argumentos a favor de estas técnicas.

Los argumentos:

Se obtiene seguridad cuantificable.

Threat Modeling Produces Measurable Security

Bien hecha, promueve el cumplimiento.

Threat Modeling Done Right Encourages Compliance

Y, finalmente, ahorra dinero.

Threat Modeling Saves You Money

Este último argumento se basa en que arreglamos problemas de seguridad en el momento en que es más barato.

Un poco de numerología (no la traduzco):

Let’s say you found 10 major problems with the architecture in those three hours. You’ve only spent $168 USD per bug to fix them. The beauty of the design phase is that there is no code to change yet.

Without the threat modeling meeting, you could find these 10 bugs in either implementation, testing, or production. What’s the cost if you did?

For the implementation phase, you’ll pay $1,008 per bug for a total of $10,080 to fix these bugs.

If found in the testing phase, you’ll pay $2,520 per bug for a total of $25,200 to fix the bugs.

If you find the bugs in production, you’ll now have to pay $16,800 per bug, for a whopping total of $168,000.

Finalmente, el modelado de amenazas -afirman- nos proporciona una fotografía en cada momento de nuestro estado, lo que nos permite tomar mejores decisiones sobre dónde invertir el dinero.

Threat modeling gives you a constant snapshot of your current security posture. This snapshot allows you to send money where it’s needed most, not based on a slideshow or product demo, but based on real data.

Interesante.

Programadores, decisiones de seguridad y riesgos

Camino Los humanos tomamos atajos. Entre un camino seguro y robusto, pero más costoso y uno fácil y directo la probabilidad de elegir el segundo es muy alta. De eso nos hablaban en Study shows programmers will take the easy way out and not implement proper password security y es un buen motivo para asegurarnos de que dentro de las especificaciones de un producto de software están los incentivos adecuados para evitar el camino fácil.

Esto es, algunas características importantes deberían estar en las especificaciones, como el almacenamiento adecuado de las contraseñas:

Freelance developers need to be explicitly told to write code that stores passwords in a safe and secure manner, a recent study has revealed.

El experimento consistía en ir a una plataforma de desarrolladores independientes (‘freelancers’) y crear un sistema de registro de una red social falsa. De los que asumieron el trabajo (43 de 260 a los que se les invitó) se decidió pagar a algunos el doble para determinar si los que cobrarían más podrían desarrollar mejor código.

Of the 43, academics paid half of the group with €100, and the other half with €200, to determine if higher pay made a difference in the implementation of password security features.

También dieron indicacciones a la mitad de los programadores para que desarrollasen el almacenamiento seguro de contraseñas, de manera explícita.

Desarrollaron el trabajo durante tres días y cuando enviaron el trabajo, directamente tuvieron que pedir a 18 que evitasen almacenar las claves en texto plano. De esos 18 había 15 que formaban parte del grupo al que no se le había solicitado un almacenamiento seguro. Esto reforzaría la idea de que los desarrolladores no dan importancia a estos detalles salvo que se les indique.

Of the 18 who had to resubmit their code, 15 developers were part of the group that were never told the user registration system needed to store password securely, showing that developers don’t inherently think about security when writing code.

De los que enviaron soluciones con almacenamiento seguro, la mayoría utilizaron sistemas que no se consideran adecuados:

Of the secure password storage systems developers chose to implement for this study, only the last two, PBKDF2 and Bcrypt, are considered secure.

8 - Base64

10 - MD5

1 - SHA-1

3 - 3DES

3 - AES

5 - SHA-256

1 - HMAC/SHA1

5 - PBKDF2

7 - Bcrypt

Se ven claramente dos grupos importantes: los que utilizan cualquier método que remotamente puede considerarse seguro (Base64 y MD5) y los que hacen su trabajo y se preocupan por elegir algunos adecuados (PBKDF2, Bcrypt). En medio, algunas elecciones no muy buenas.

De los que recibieron la petición de desarrollar utilizando un sistema seguro 3 eligieron Base64 (mal) y sólo 15 de los 43 eligieron un sistema con ‘salt’ (recordar que estos sistemas sirven para evitar que se puedan detectar contraseñas iguales, entre otras virtudes).

Furthermore, only 15 of the 43 developers chose to implement salting, a process through which the encrypted password stored inside an application’s database is made harder to crack with the addition of a random data factor.

Los ‘horrores’ no terminan aquí porque un nada despreciable número de 17 desarrolladores copiaron directamente el código de sitios de internet, lo que los autores del estudio creen que indica que no tenían las habilidades necesarias para desarrollarlo por su cuenta.

The study also found that 17 of the 43 developers copied their code from internet sites, suggesting that the freelancers didn’t have the necessary skills to develop a secure system from scratch, and chose to use code that might be outdated or even riddled with bugs.

No había diferencias significativas para los desarrolladores que ganaban más.

Así que, como consejo, si queremos tener sistemas seguros deberíamos tener especialistas que ayuden a definir correctamente las especificaciones y que eviten tomar decisiones basadas en creencias y ‘folklore’.

Se puede leer el artículo en [PDF] “If you want, I can store the encrypted password.”A Password-Storage Field Study withFreelance Developers.

Analizando vulnerabilidades por lenguajes

Seguridad en software Nos pongamos como nos pongamos, hay lenguajes de programación que nos facilitan más que otros el desarrollo de código seguro. Eso no significa que podamos utilizarlos y quedarnos tranquilos, pero si podemos elegir deberíamos tenerlo en cuenta.

En The 3 least secure programming languages nos contaban sobre un estudio que trataba de analizar este tema, con un estudio que analiza código disponible en diversos repositorios, sistemas de gestión de incidencias y los informes de vulnerabilidades de una de las bases de datos que se utilizan para estas cosas. La noticia es bastante flojilla, pero si alguien está interesado en el informe se puede ver en What Are The Most Secure Programming Languages pasando, eso sí, por un pequeño registro a su ‘boletín’.

… the report compiled information from WhiteSource’s database, which aggregates information on open source vulnerabilities from sources including the National Vulnerability Database (NVD), security advisories, GitHub issue trackers, and popular open source projects issue trackers. Researchers focused in on open source security vulnerabilities in the seven most widely-used languages of the past 10 years to learn which are most secure, and which vulnerability types are most common in each.

Los lenguajes más ‘populares’ cuando hablamos de vulnerabilidades por lenguaje serían:

C (47%)

PHP (17%)

Java (11%)

JavaScript (10%)

Python (5%)

C++ (5%)

Ruby (4%)

Se refiere al número total de errores, así que la popularidad de un lenguaje influye (más usos, más errores). En el informe lo aclaran, que es algo que no se hace en el artículo de prensa:

For starters, more code has been written than any other language, providing more opportunities for vulnerabilities to be discovered. The fact is that C has been in use for much longer than most other languages, and is behind the core of most of the products and platforms we use. As such, it is bound to have more known vulnerabilities than the rest.

Las vulnerabilidades más frecuentes son el ‘cross site scripting’, validación de entradas, permisos, privilegios y control de acceso; finalmente divulgación de información.

Sin embargo, si leemos el informe, la imagen cambia un poco. En el año 2018, además del omnipresente C, Javascript, Java y PHP aparecen como fuente de errores de gravedad alta. Con números mucho más próximos entre sí.

Estos informes hay que leerlos siempre con un cierto escepticismo: malos desarrolladores harán mal código en cualquier lenguaje. Pero me parecen muy interesantes para conocer cómo está el mundo.

Eficiencia en Python al ordenar

Velocidad Un artículo muy chulo comparando los métodos de ordenación en Python, que se puede leer en list.sort() vs. sorted(list).

El primero es un método asociado a los objetos de tipo lista, y el segundo una función estándar para ordenar listas.

Vale la pena leerlo con calma para aprender un poco cómo hacer estas comparaciones, qué hay que tener en cuenta y todo eso. Pero para gente ansiosa, podemos decir que list.sort es algo más rápido y consume menos memoria. Tiene el inconveniente, eso sí, de que perdemos la lista original (porque reordena sobre la propia lista).

Una guía sobre cookies para la web

Fabricando galletas. En la vocación de divulgación y aprendizaje de este sitio traemos otro artículo de esos que sirven de recordatorio para la gente más experimentada, y de aprendizaje para la más nueva.
Se trata de Ultimate Guide to HTTP Cookies y es justamente eso, una guía sobre las denostadas (y necesarias) cookies en la navegación web.

Primero, recordar que las cookies se suelen utilizar principalmente para la gestión de sesiones (autenticación), seguimiento de usuarios y personalización.

There are three main reasons why we need cookies:

Authentication (session management)

User tracking

Personalization (theme, language selection, etc.)

Conviene recordar que la web funciona sobre el protocolo HTTP (Hypertext Transfer Protocol), que a su vez se ejecuta sobre el protocolo TCP (Transmission Control Protocol) y que se trata de un protocolo sin estado. Esto es, hacemos una petición, el servidor web la responde y ‘se olvida’ de nosotros. El concepto de programa (y, por lo tanto, el de aplicación web) va íntimamente ligado a la idea de estado (instrucciones que se ejecutan sobre una serie de datos que van cambiando en el tiempo sus valores) así que es necesario mantener esa información para que puedan existir las aplicaciones web.

Muy interesante, y aclararemos algunos conceptos (o los recordaremos) con la lectura.

Información sobre Cross Site Request Forgery en OWASP

Cruce Las ‘chuletas’ de OWASP (OWASP cheatsheets) son una buena fuente de información para refrescar nuestras ideas o para abordar algún tema que no conocemos en profundidad. En esta ocasión traemos la de Cross Site Request Forgery Prevention Cheat Sheet, que ha sido recientemente actualizada y revisada.

Primero recordar que el ‘Cross Site Request Forgery (CSRF)’ es un problema que se basa en la realización de alguna acción en un sitio web en el que estamos autenticados mediante un enlace en otra parte (un sitio web malicioso, mensaje, correo, …). Es posible cuando el sitio no valida correctamente que la petición ha sido realizada de la manera adecuada (esto es, que el enlace en el que pinchamos está en un sitio adecuado) y puede provocarnos algún dolor de cabeza:

Cross-Site Request Forgery (CSRF) is a type of attack that occurs when a malicious web site, email, blog, instant message, or program causes a user’s web browser to perform an unwanted action on a trusted site when the user is authenticated.

La forma de defenderse es conocida desde hace tiempo, y la mayoría de entornos de desarrollo proporcionan herramientas para que no tengamos que preocuparnos (demasiado) de estos problemas pero hay que recordarlo si decidimos trabajar ‘sin red’ y desarrollar nosotros mismos alguna aplicación web sin apoyo de un ‘framework’ adecuado.

Interesante.

Se pueden ver otras ‘chuletas’ en CheatSheets.

Introducción e historia de los contenedores

Contenedor y herramientas Aunque de manera profesional son algo de nuestro día a día, en el apartado de ‘cosas que han sucedido mientras no estábamos atentos’ han explotado en los últimos años los contenedores: por decirlo de manera muy simplificada, un contenedor es un sistema virtual que nos permite aislar un ‘programa’ y sus dependencias de forma que no interfiere con otros procesos dentro del mismo sistema donde se ejecuta, pero de manera más ligera que si ejecutáramos una máquina virtual para él solo.

En The Missing Introduction To Containerization hablan del tema, empezando con un repaso histórico: las jaulas ‘chroot’, y otras tecnologías que se han venido usando con la misma finalidad.

It all started when the Chroot Jail and the Chroot system call were introduced during the development of Version 7 Unix in 1979. Chroot jail is for “Change Root” and it’s considered as one of the first containerization technologies.

Lectura interesante.

¿Dónde guardas tus secretos?

Escondido El otro día hablábamos de fugas de información a través de los canales de comunicación de las empresas y cómo los ‘malos’ podían sacar partido de diversos automatismos en Interacciones inseguras entre sistemas de ayuda y otros. Hoy traemos otro How bad can it git? Characterizing secret leakage in public GitHub repositories relacionado con la difusión de secretos que no deberían estar en los sistemas de control de versiones.

Los desarrolladores no deberían incluir secretos en los sistemas de control de versiones, nada nuevo:

On the one hand you might say there’s no new news here. We know that developers shouldn’t commit secrets, and we know that secrets leaked to GitHub can be discovered and exploited very quickly.

Ofrecen expresiones regulares que podrían utilizarse como chequeo antes de enviar la información al sistema de control de versiones, que pueden encontrarse en el artículo, en How Bad Can It Git? Characterizing Secret Leakage in Public GitHub Repositories.

Hay una implementación previa, que incorpora el sistema en truffleHog y otro proyecto con ideas similares git-secrets.

Vale la pena leerlo todo, muy interesante.

¿Eres predecible?

Sorteo En How random can you be? una vez más un recordatorio sobre lo poco hábiles que somos generando aletaoriedad (y comprendiéndola, usándola, manejándola, …).

Hay un jueguecito que podemos probar donde el sistema trata de adivinar nuestro próximo movimiento y nos dice si va acertando o no.

También hay algo más de información sobre el tema en los enlaces. Interesante.