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.

En strong_password v0.0.7 rubygem hijacked Tute Costa nos cuenta cómo descubrió que alguien había robado una cuenta y había cambiado una de las gemas (gems) que utiliza su aplicación.

Aparentemente, le habían robado las credenciales al autor a través de uno de esos robos habituales en diversos servicios y la mala práctica de reutilizar las contraseñas entre distintos servicios. Sin doble factor de autentificación.

Además, el mensaje podría ser que estas cosas pasan hasta en las mejores familias. O algo así.

Una lectura interesante en What I Learned Trying To Secure Congressional Campaigns donde Maciej Cegłowski nos cuenta su trabajo en la campaña de las elecciones en EEUU y su trabajo para tratar de llevar la seguridad informática a diferentes colectivos implicados con esta campaña. En particular, los candidatos, sus equipos y familias.

Todos tenemos más o menos clara la idea de lo que hay que aconsejar en términos de segurida informática a una persona de la calle. Sin embargo, no todo el mundo se ha puesto a trabajar de la mano con gente real para ver cómo podrían aplicar esos consejos. Y el autor tiene esa experiencia y nos la cuenta.

This article is specifically about campaign security, or how to keep candidates and their staff and families safe from people trying to break into social media, read their email, or wire their campaign war chest to Nauru. There are a lot of even more hopeless problems, like election security, but as you will see there is plenty to lose hope about just in this corner of the problem space.

Se trata de preocuparse de los aspectos técnicos, pero no sólo de ellos.

I fear that by fixating on the technical content of the briefings, we are missing an opportunity for a much richer, more satisfying nerdfight about process.

Y es difícil hasta conseguir la atención de estas personas, cuyo tiempo es escaso y tiene otras prioridades:

… is the hard part. Like Mike Tyson says, “everybody has a plan until they’re punched in the face.” Everyone has security checklist for campaigns until they try to schedule a meeting.

Por supuesto, tener en cuenta que no se tiene el mejor equipamiento, ni los mejores programas ni, por supuesto, el dinero necesario para esta parte.

You have to accept the fact that computers are broken, software is terrible, campaign finance is evil, …

Ofrecer ayuda en seguridad informática cuando no hemos tenido ningún incidente es como ofrecer una limpieza dental: todo el mundo entiende que es interesante, pero pueden dejarlo de lado con un pequeño sentimiento de culpa.

Offering security training is like being a dentist offering a teeth cleaning. Everyone understands in the abstract that this is something they need. They feel guilty about putting it off. Maybe if you are really persuasive and can talk in scary terms about gum disease, they will agree to do it. But they will not enjoy it, and however much they promise, they are never going to floss.

Yendo a los aspectos más prácticos, conviene centrarse en lo que realmente necesitan:

Collect information about what devices people are using, their email provider, whether they have two-factor authentication, how they share documents in the campaign, how they keep track of passwords, and so on. Explain that you are not a Russian spy. Make them do all their overdue software updates in front of you while you start part 2 (10 minutes).

Aconsejar sobre el uso del doble factor de autentificación.

Introduce U2F security keys and explain how they prevent the kind of attack that ensnared John Podesta. Demonstrate how to use them and what to do if you lose them. Have everyone open their laptop and walk them through the setup, then demo a trial login, with the key and with a backup method. (30 minutes)

Hablar del correo y los adjuntos y ayudar con estrategias para mejorar un poco la seguridad.

Talk about email and attachments. This part is almost like sex education: you preach abstinence, but you know the moment you leave the room, they’ll be double-clicking on whatever Excel spreadsheet the DCCC forwarded them that day. Explain high-risk behaviors, low-risk behaviors, and how to open stuff more safely in GDrive. Try to push the campaign towards shared Google Docs and Signal instead of email. (20 minutes)

Finalmente recomienda hablar de los dispositivos y buenas costumbres sobre contraseñas.

If additional time is available, talk about devices and password habits.

Mucha gente muy productiva parece tener muy malas costumbres.

Sometimes the most productive people on a campaign are volunteers with unfixable bad technology habits.

Es mejor dar consejos concretos y sencillos que muy amplios y difíciles de aplicar.

Nobody acts on the DNC/Belfer Center Cybersecurity Campaign Playboook recommendations, because they are too vague. I found it best to treat the Belfer document as a revered holy text that required exegesis to be understood by the faithful.

También puede ser una buena idea hablar de niveles de seguridad y facilitar el camino para ir mejorándola poco a poco.

Talking about degrees of safety, and giving people an incremental path to secure behavior. For example, we told campaigns it was best to have a password manager, okay to have a written list of random passwords, dangerous to have a password pattern you would modify across sites, and unacceptable to re-use a single password across sites .

También evitar avergonzar a la gente o maltratarla: su trabajo no es asegurar sus herramientas de trabajo ni solucionar los problemas que otros están creando continuamente.

Shame reduction. I tried to emphasize to people that there was an entire security community rooting for them, and that it shouldn’t be their job to have to get all these broken technologies right. I learned if you refrain from shaming people, they will eventually confess some horrific sins, and snitch on others.

Las analogías relacionadas con la salud pública pueden funcionar: porque el mensaje de la salud ya está en nuestro ideario, porque son aplicables, hacen que la gente esté más segura y no están dirigidas a público especializado.

Using public health analogies. It was tricky at first to figure out how to convince people the threat was real without scaring them into apathy. The analogy to public health did the job. I told people they were getting the ‘wash your hands, boil your water’ version of security advice, which communicated several ideas: that the guidelines were practical, that they made people safer, and that they weren’t targeted at “tech” people.

Los gestores de contraseñas son un buen consejo, pero no es sencillo empezar a utilizarlos.

Password managers. I was never able to find a way to set people up on a password manager in the time available. Let me be very clear: I would like all people to use a password manager. Every night, I dream of a world where people use password managers.

But I never found a way to get people onto 1password in a single training session.

Si no se puede usar un gestor de contraseñas, no está mal aprender a generar una contraseña larga y única y apuntarla en la aplicación de notas del teléfono.

In the end, I told candidates to generate unique passwords and save them in the notes app on their phone, or write them down on a card they kept in their wallet. And I’d do it again!

Creo que es una buena lectura.