Concurrencia en Python

Hilos Por ahora Python no es el lenguaje de programación con mejores características de concurrencia (fundamentalmente, el intérprete no es lo que se llama `thread safe’ así que hay que imponer restricciones para que las cosas funcionen Global Interpreter Lock). Esto no significa que no haya primitivas para gestionar la concurrencia y que, en algunos casos, podamos obtener ventajas de la concurrencia.

Por eso (y porque la concurrencia es un tema que me gusta mucho) traigo aquí An Intro to Threading in Python que me pareció una buena introducción al tema, didáctica y con ejemplos, sin olvidar el tema de las condiciones de carrera.

Allí también nos recuerdan que la concurrencia es limitada:

But for most Python 3 implementations the different threads do not actually execute at the same time: they merely appear to.

Y que si queremos ir más allá tendremos que utilizar un intérprete no estándar:

Getting multiple tasks running simultaneously requires a non-standard implementation of Python, writing some of your code in a different language, or using multiprocessing which comes with some extra overhead.

No obstante, es un tema interesante para explorar y siempre podremos obtener las ventajas típicas de la concurrencia, que consisten en poder hacer avanzar algunas tareas cuando otras se quedan atascadas (en operaciones de entrada/salida, o esperando algún evento, …). En otros casos no vamos a obtener una ventaja real, pero siempre está bien utilizar este lenguaje para aprender conceptos que luego pueden utilizarse en otros.

Sobre el tamaño y el desarrollo de Windows 10

Ventanas A través de Un ingeniero de Microsoft explica cómo es Windows 10 por dentro: el código ocupa 0,5 TB y se extiende por 4 millones de ficheros llegamos a unos cuantos datos e informaciones sobre las interioridades de Windows 10 que se agradecen, porque no siempre ha sido muy fácil conocer estas cosas.

Como lenguaje de programación se utiliza fundamentalmente el C, aunque también hay código en C#, JavaScript, TypeScript, VB.NET o C++.

Sobre el tamaño, como dice el titular, estamos hablando de que

Según explica Rietschin, el árbol completo con todo el código fuente, el código de prueba y todo lo que constituye el “código fuente de Windows” tiene más de medio terabyte de tamaño, en más de 4 millones de archivos

Muy interesante y para guardar como referencia.

Actualización (2019-09-18): En Which programming language is used for making Windows 10? podíamos leer algo más de información relacionada con el tema.

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.