Una lectura interesante en Operating a Large, Distributed System in a Reliable Way: Practices I Learned sobre la experiencia del autor, Gergely Orosz, en sistemas distribuidos.

Habla de temas como la monitorización, detección de anomalías, gestión de incidentes y muchos otros aspectos que alguien con poca experiencia en este tipo de sistemas podría pasar por alto (o aprender por la vída difícil).

Lo hace desde la experiencia de trabajar con el sistema de pagos de Uber y nos recuerda que cuanto más grande es el sistema, más probable es que se cumpla la máxima aquella de que ‘si algo puede ir mal, irá mal’.

The larger a system, the more Murphy’s law of “what can go wrong, will go wrong” applies. This is especially true with frequent deploys, lots of developers deploying code, multiple data centers involved, and the system being used globally by a large number of users.

Muy interesante.

Seguimos dando consejos acerca de las contraseñas (longitud, complejidad, …) aunque lo cierto es que cada vez los sistemas confían menos en ellas y utilizan otro tipo de medidas (segundo factor, principalmente, por elección del usuario o porque el proveedor nos lo suministra cuando tiene dudas).

Por eso me gusta leer todo lo que puedo sobre contraseñas, sistemas de identificación, autentificación y me gustó leer Your Pa$$word doesn’t matter donde se habla de este tema.

Dice que la contraseña no importa:

Because here’s the thing: When it comes to composition and length, your password (mostly) doesn’t matter.

Los atacantes, típicamente, quieren conseguir claves para tener acceso a alguna cuenta (sin un objetivo concreto). Los métodos más sofisticados sólo se usan para objetivos concretos que merecen el esfuerzo.

To understand why, let’s look at what the major attacks on passwords are and how the password itself factors into the equation for an attacker. Remember that all your attacker cares about is stealing passwords so they, or others, can access accounts. That’s a key difference between hypothetical and practical security – your attacker will only do really wacky, creative stuff you hear about at conferences (or wherever) when there’s no easier way and the target of the attack justifies the extra effort.

Asi, conseguir credenciales es relativamente sencillo porque se pueden comprar de ataques anteriores, o mediante phishing, instalando un ‘malware’ y espiando nuestro teclado, y otras medidas similares para las que no importa cómo de compleja sea la contraseña.

Una contraseña ‘diferente’ ayuda cuando el atacante está ‘probando’ diferentes claves y para evitarlo basta con tener una que no sea muy común.

But again, the average attacker is moving so slowly in response to detection systems that they only get a few guesses in. So, your password only matters if it’s included in that short list the attacker is trying. As an admin, you want to prevent use of these commonly attacked passwords when passwords are created or changed.

Si el atacante consigue acceder a la base de datos de claves, es cuestión de tiempo que lo consiga salvo que nuestra clave sea verdaderamente buena.

The point is – your password, in the case of breach, just doesn’t matter – unless it’s longer than 12 characters and has never been used before – which means it was generated by a password manager. That works for some, but is prohibitive for others. If you are using a password manager, use the maximum possible length – there’s no usability downside if you are already cutting and pasting.

Interesante.

Recientemente se ha hablado en España del tema de anonimización de datos de ciudadanos (lo contaba en Demoscopía tecnológica: Un gobierno que tome decisiones basadas en datos) porque creo que es un buen camino para conocer mejor a los ciudadanos y proporcionarles un buen servicio.

No obstante, soy consciente de que cuando se habla de anonimización, hay que manejar los términos con cuidado. Y por eso me gustó leer Hashing names does not protect privacy; esto es, utilizar un hash de los nombres (o de los identificadores) no tiene por qué supone una anonimización efectiva, sobre todo si el atacante sabe que la entrada proviene de un conjunto de datos restringido (¿números de teléfono? ¿matrículas?).

But you know the input comes from a restricted set, a set small enough to search by brute force, then hash functions are reversible. If I know that you’ve either hashed “yes” or “no,” then I can apply the hash function to both and see which one it was.

Sobre datos personales, siempre estaremos trabajando con un conjunto de datos pequeños donde un ataque de fuerza bruta tiene sentido (sobre todo si se buscan los datos de alguien en particular).

Suppose someone has attempted to anonymize a data set by hashing personally identifying information (PII) such as name, phone number, etc. These inputs come from a small enough space that a brute force search is easy.

Los números son más costosos

Hashing numbers is simpler but more computationally intense. I had to do a little research to find a list of names, but I know that social security numbers are simply 9-digit numbers. There are only a billion possible nine-digit numbers, so it’s feasible to hash them all to make a look-up table.

Para mejorar la situación la propuesta tampoco es muy complicada: en lugar de utilizar el dato, generar una clave que podemos combinar con los valores reales antse de hacer el hash.

One way to improve the situation would be to use a key, a random string of bits that you combine with values before hashing. An attacker not knowing your secret key value could not do something as simple as what was described above.

En temas de seguridad y privacidad siempre hay que ir un poco más allá.

Microsoft lleva años mejorando las herramientas y procedimientos para desarrollar código más seguro. En esa línea podemos leer A proactive approach to more secure code donde se habla del problema que suponen los fallos de corrupción de memoria y cómo tratar de evitarlos eligiendo (cuando sea posible) mejores lenguajes desde este punto de vista:

as Matt Miller discussed in his 2019 presentation at BlueHat IL, the majority of vulnerabilities fixed and with a CVE assigned are caused by developers inadvertently inserting memory corruption bugs into their C and C++ code. As Microsoft increases its code base and uses more Open Source Software in its code, this problem isn’t getting better, it’s getting worse.

Tenemos herramientas, pero los desarrolladores no tienen tiempo para usarlas y también existen cada vez más lenguajes que son seguros desde el punto de vista de gestión de la memoria

If only the developers could have all the memory security guarantees of languages like .NET C# combined with all the efficiencies of C++. Maybe we can: One of the most promising newer systems programming languages that satisfy those requirements is the Rust programming language originally invented by Mozilla.

Y también tenemos modelos, como la industria del automóvil y todo lo que ha mejorado la seguridad de los viajeros en la evolución de sus procesos.

We can learn from the way the automotive industry continually evolves their technology to protect drivers and road users. The software security industry has a prerogative to protect the developer in a similar manner. Perhaps it’s time to scrap unsafe legacy languages and move on to a modern safer system programming language?

Habrá que conocer mejor Rust.

En los últimos tiempos es frecuente oir recomendar (yo mismo lo hago a veces) usar un gestor de contraseñas y activar el doble factor de autentificación (esto no tanto). En Before You Use a Password Manager nos recuerdan algunas cuestiones intersantes sobre el tema. No voy a seleccionar todos los temas que trata, pero si algunos que me llaman más la atención.

Un gestor de contraseñas puede ser un riesgo para tus contraseñas, porque puedes olvidar la clave maestra:

You may forget the master password that protects your other passwords. Once you’ve replaced your passwords with random passwords, and relied on your password manager to enter them for you, you’re unlikely to be able to remember many of them anymore — the initial selling point of password managers was that you shouldn’t have to. If you lose the master password that the password manager uses to protect your other passwords, you could lose everything. There are recovery options, but none is perfect, as I’ll discuss later.

Si alguien consigue atacar con éxito el gestor, tenemos un problema:

An attack on your password manager can reveal all your passwords. This includes attacks on any device on which you store you managed passwords.

También pueden ocurrir otros problemas, como infecciones con malware:

If your personal laptop is infected with malware and you use your password manager on it, the malware can read every password you keep there.

Y también hay que proteger los dispositivos adecuadamente:

If you use your password manager on a tablet and leave the password manager unlocked, anyone with the tablet can access all your passwords.

Sin olvidar que el gestor es un programa y que puede tener sus propios problemas de seguridad.

Lastly, a password manager is yet another piece of software installed on your devices that could become compromised. All software has bugs and, despite being developed to meet a security need, password managers have been far from immune to security bugs.

Un recordatorio de que no hay una solución perfecta.