Un gestor de contraseñas también puede traerte problemas

Puerta de protección 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.

Alguien cambió lo que no debía. Un caso real

Vidrios de colores 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í.

Seguridad para gente normal

El baño 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.

Cabeceras más humanas para la web

La web De vez en cuando encontramos una entrada como esta y la recomendamos: HTTP headers for the responsible developer habla justamente de eso, las cabeceras que se recomienda enviar hoy en día pensando en la seguridad y en un trato adecuado a nuestros lectores. Si se puede, claro.

Como desarrolladores tenemos una responsabilidad, que es construir cosas que ayudan y dan fuerza a las personas.

Developers have the power to build the web for everyone, but that power needs to be used responsibly. What matters, in the end, is building things that help and enable people.

Luego hablan de las cabeceras relacionadas con una conexión segura, con una política adecuada de contenidos (CSP)… Pero también se preocupan del coste (que no haga falta una máquina de última generación para poder usar nuestro sitio, por ejemplo).

While I write this article, I sit in front of a relatively new MacBook using my fast Wi-Fi connection at home. Developers often forget that a setup like this is not the default for most of our users. People visiting our sites use old phones and are on crappy connections. Heavy and bloated sites with hundreds of requests give them a bad experience.

También con respeto para los usuarios, no hacerles esperar, no molestarles innecesariamente…

Finalmente, también nos recuerda que debe ser para todo el mundo.

In this article, I only covered a few headers that could help improve the user experience. If you want to see an almost complete overview of headers and their possibilities I can recommend having a look at Christian Schaefer’s slide deck “HTTP headers – the hidden champions”

Muy interesante.

Las credenciales se pueden escapar por donde menos te lo esperas

Cerrado En Git ransom campaign incident report—Atlassian Bitbucket, GitHub, GitLab una nota que emitieron Bitbucket, GitHub y GitLab sobre el secuestro de sitios gestionados dentro de sus sistemas.

Today, Atlassian Bitbucket, GitHub, and GitLab are issuing a joint blog post in a coordinated effort to help educate and inform users of the three platforms on secure best practices relating to the recent Git ransomware incident.

Algunos usuarios entraban a la plataforma y se encontraban con que alguien había entrado en sus cuentas y había ‘secuestrado’ su contenido. Aparentemente se debería al despiste de estos usuarios que habrían divulgado sus credenciales de alguna forma.

Each of the teams investigated and assessed that all account compromises were the result of unintentional user credential leakage by users or other third-parties, likely on systems external to Bitbucket, GitHub, or GitLab.

En estos sitios se observaba actividad de datos en el fichero .git/config y otros parecidos que, en algunas ocasiones contenían credenciales, tokens de acceso y otros datos sensibles.

Further investigation showed that continuous scanning for publicly exposed .git/config and other environment files has been and continues to be conducted by the same IP address that conducted the account compromises, as recently as May 10.

Los consejos para protegerse son los de siempre: utilizar doble factor, utilizar claves fuertes y únicas para cada sitio, utilizar un gestor de contraseñas…

Use strong and unique passwords for every service.

Y, con respecto a los tokens de acceso, considerarlos como credenciales y gestionarlos de manera adecuada (lo que incluye no ponerlos en el propio código).

Algunas ideas sobre código correcto

Un contrato... Otra lectura interesante, Foundations of Correct Code donde se habla de que el código no sólo ha de pasar los tests y las pruebas, sino que estas deben tener en cuenta que el código sea correcto.

En este sentido nos recuerda los conceptos de los contratos, pre y post-condiciones y nos recuerda su historia:

You may well have heard the terms before: contract, pre-condition, post-condition. But you might not be aware of their origins.

Posteriormente, entra en la discusión entre lo que llamamos programación defensiva (si no se cumple lo que esperamos lanzamos un error antes de hacer algo que, a priori, puede ser incorrecto) o bien el diseño por contrato, basado en el principio de que si el proveedor cumple su parte, nosotros devolveremos un resultado correcto.

We have two choices here: defensive programming, and Design by Contract.

Defensive programming guards the body of a function or method, checking that the pre-condition holds and throwing an error if it doesn’t.

all of the interactions between its components must be correct. A Hoare triple describes a contract between a client and a supplier of a service (e.g., a method of a class), such that the supplier ensures that the post-condition is satisfied, and the client ensures that they never a method or function unless the pre-condition is satisfied.

A la hora de elegir, puede depende de nuestra relación con el resto de proveedores: si nosotros producimos todo el código, hay cosas que podemos (o deberíamos poder) asegurar. En otros casos, tenemos que tener cuidado con lo que hayan podido hacer otras personas.

One final thought on defensive programming vs. Design by Contract, relating to the design of the system as a whole: when it’s us writing the client code, we have control over whether the inputs are correct. When someone else is providing the inputs – e.g., a web service client, or an end user – we don’t have that control. So it’s usually necessary to code defensively at system/service boundaries.

Tampoco tiene sentido conformarse con lanzar un error cuando algo no vaya bien: normalmente el usuario puede que ni siquiera tenga la culpa y nosotros tampoco queremos molestarle.

Offering users choices that aren’t actually available and then displaying an error message when they select them not only annoys the user, but also complicates the application’s internal logic as it now has to handle more edge cases.

De esta forma, es posible que tengamos que usar ambas aproximaciones:

I’ve found the best approach to delivering correct software that’s simple in its internal logic is to design the UX carefully to simplify the inputs, do some defensive programming just below the UI to validate the inputs, and then apply Design by Contract for all the internal logic, with test-time assertion checking in case we made a boo-boo in some client code.

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.