Ahora que es raro (aunque posible, todavía) ver sitios o programas que conserven las contraseñas en lugar de las versiones modificadas (hash) me gustó leer Bcrypt at 25: A Retrospective on Password Security .

Lo firma Niels Provos, uno de los autores de bcrypt (en el año 1997) y la primera sorpresa después de 25 años es que seguimos utilizando contraseñas.

As one of the creators of bcrypt back in 1997, I find it somewhat surprising that, 25 years later, we still rely heavily on passwords.

Habla después de los sistemas compartidos, donde la seguridad de la contraseña no se consideraba crítica (eran entornos de colaboración)

This came over the strenuous objections of Richard Stallman who famously tried to resist the introduction of passwords at MIT in the 1970s (Levy, 1984).

Y la introducción del primer sistema de hashing un poco robusto en los sistemas Unix, de la mano de sus primeros autores:

Unix, developed in the 1970s by Ken Thompson and Dennis Ritchie, introduced a more robust password hashing function called crypt.

Pero todavía hacía falta tener en cuenta la capacidad de cálculo que iban teniendo los sistemas y la importancia de dificultar la prueba por fuerza bruta para conseguir adivinar las contraseñas.

The concept of adaptive hashing, which made brute force and dictionary attacks more and more computationally demanding, was the brainchild of David Mazières.

El problema que se trataba de solucinar era el robo de bases de datos de contraseñas de sistemas comprometidos: una vez que se comenzaron a almacenar transformados, lo que tenían que hacer los atacantes es probar con listas de contraseñas frecuentes, o probar todas las combinaciones (fuerza bruta) y pescar lo que se pudiera.

Consequently, various tools emerged to guess common passwords and compare them with the hashed passwords in the user database. These tools typically employ a combination of dictionary attacks, brute force and other techniques to guess potential passwords and check them against stored hashes (Bonneau, 2012). John the Ripper, L0phtCrack, Hashcat, and Hydra are some popular examples of password cracking tools.

Cuando un atacante consigue algunas de estas contraseñas, puede probarlas en diferentes servicios, consiguiendo con frecuencia acceder a información interesante.

When attackers successfully recover passwords from a database dump, they can then try them on different servers and sites, often gaining access to email accounts or other sensitive user data.

La introducción de bcrypt supuso un avance interesante por el factor de coste ajustable (esencialmente, se puede ‘tunear’ con parámetros de configuración para que sea más costoso de calcular conforme aumenta la velocidad de los procesadores).

This critical feature allowed bcrypt to keep pace with computing power advancements, maintaining its robustness against evolving threats.

Como es natural, la existencia de buenos algoritmos no significaba que se estuvieran utilizando, como muestran algunos ejemplos. LinkedIn (SHA-1), Yahoo! (MD5, SHA-1, bcrypt), Adobe (SHA-1), MySpace (SHA-1)…

Sadly, industry adoption hasn’t been as swift as I had hoped. Even after introducing bcrypt and other more secure password hashing algorithms, numerous high-profile data breaches have occurred involving passwords hashed with weaker algorithms.

Y, como decíamos arriba, el factor de la potencia de cálculo: en 34 años se ha pasado de poder calcular 45 claves por segundo a 6.3 miles de millones, pulverizando (en este tema) las predicciones de la ley de Moore.

Over the course of 34 years, we’ve witnessed an extraordinary leap in the password guessing speed for DES-crypt; it’s accelerated from a mere 45 passwords per second to an astounding 6.3 billion passwords per second. This advance doesn’t just surpass Moore’s law — it pulverizes it, tripling the password cracking speed every two years.

Termina recordándonos que las contraseñas ya no son un gran problema y ni siquiera la seguridad es ya un problema técnico:

In my experience, most security professionals consider password security a solved problem from a technical perspective. I would even go further and claim that security is no longer a problem that I consider to be primarily technical.

Sin embargo, sí que es importante tomar las decisiones técnicas adecuadas, que no es algo que venga disponible ‘en una caja’ para todo el mundo.

Let’s talk about adopting security technologies first. Currently, there are no off the shelf solutions that lead to good security outcomes.

La mayoría de las empresas siguen buscando el compromiso (cuando lo buscan) entre la seguridad y gasto.

Most other companies usually seek to choose an appropriate trade off between investing in business growth and security.

Porque los incentivos siguen siendo hacer crecer el negocio y gestionar los problemas de seguridad cuando aparezcan.

The incentives are such that it is the rational argument to invest in business growth and treat a data breach as an eventuality that will be dealt with when it happens.

Sin embargo, para las empresas con un nivel adecuado de madurez la preocupación es más bien por los aspectos humanos, fundamentalmente el riesgo que pueden provocar nuestros propios empleados.

For the few companies that achieve a mature security posture, human factors often dominate their security concerns, and insider risk becomes the primary focus.

Buena lectura.

Hoy venimos casi a hablar de fundamentos. Pero … ¿construimos continuamente aplicaciones sobre las redes y no conocemos bien lo que sucede?

En An overview of the OSI model and its security threats nos habla de los siete niveles del modelo Open Systems Interconnection (OSI) (nivel de aplicación, presentación, sesión, transporte, red, enlace de datos y físico) y de los posibles ataques a cada uno de ellos.

La seguridad de un sistema complejo es complicada y no conviene olvidar que los ataques se pueden desarrollar a muchos niveles.

Es fácil encontrar información sobre criptografía y su uso, pero no lo es tanto encontrar información actualizada: un algoritmo, una recomendación que era prudente y sensata hace algún tiempo puede haber dejado de serlo ya.

Por eso es bueno tener fuentes recientes y que se actualizan (al menos, mientras lo hagan). En este caso Cryptographic Best Practices con recomendacioens concretas y bastante al día de qué usar según nuestras necesidades.

En Uncovering the unheard: Researchers reveal inaudible remote cyber-attacks on voice assistant devices nos cuentan una nueva preocupación para los que tengan asistentes basados en la voz.

La idea parece ser enviar instrucciones al dispositivo que no sean audibles para los humanos. Como todos sabemos hay frecuencias que el oido humano no puede percibir y, en este caso, usando aquellas que están cerca del espectro ultrasónico pueden atacar a estos dispositivos.

The researchers developed Near-Ultrasound Inaudible Trojan, or NUIT (French for “nighttime”) to study how hackers exploit speakers and attack voice assistants remotely and silently through the internet.

Técnicamente, nos dicen, la solución es sencilla pero es necesario conocer el ataque para adoptarla.

“The technically interesting thing about this project is that the defense solution is simple; however, in order to get the solution, we must discover what the attack is first,” said Xu.

Este tipo de ataques aprovecharían alguno de los altavoces que podemos tener conectados a internet para reproducir algunas instrucciones que podrían desencadenar alguna autorización para poder hacer cosas más ‘interesantes’. Y quien dice un altavoz conectado a internet dice un altavoz que usamos en una videoconferencia, o escuchando un vídeo de YouTube y otras situaciones similares.

“If you play YouTube on your smart TV, that smart TV has a speaker, right? The sound of NUIT malicious commands will become inaudible, and it can attack your cell phone too and communicate with your Google Assistant or Alexa devices. It can even happen in Zooms during meetings. If someone unmutes themselves, they can embed the attack signal to hack your phone that’s placed next to your computer during the meeting,” Chen explained.

Cuidado.

En How a single line of code brought down a half-billion euro rocket launch la historia del lanzamiento en 1996 del cohete Arianne 5 y su explosión 40 segundos después del lazamiento.

Just 40 seconds after take-off, however, huge chunks of metal and burning fragments of Ariane Flight 501 are crashing down over the launch area. A shocking disaster for the ESA and a rough setback for the mission.

¿El problema? Un trozo de código, que provenía de la misión Arianne 4 y que ni siquiera se utilizaba.

The cause? A simple, and very much avoidable coding bug, from a piece of dead code, left over from the previous Ariane 4 mission, which started nearly a decade before. Here’s what happened exactly.

El problema se debió a un fallo típico de desbordamiento pero de los que ni siquiera se suele hablar mucho: cuando se convierte un número real de 64 bits en uno de 16 bits con signo.

To achieve this, the guidance system converts the velocity readings, from 64 bit floating point to 16 bit signed integer.

Si hacemos las cuentas, con 16 bits podemos almacenar cualquier número entre 0 y 65535 sin signo, y entre -32768 y 32767 si contemplamos números con signo.

With 16-bit unsigned integers, you can store anything from 0 to 65,535. If you use the first bit to store a sign (positive/negative) and your 16-bit signed integer now covers everything from -32,768 to +32,767 (only 15 bits left for the actual number). Anything bigger than these values and you’ve run out of bits.

Por otra parte, los números reales se almacenan de manera diferente porque tṕicamente almacenan números más grandes y, además, deben gestionar la parte decimal (me gustó como lo cuentan en Examples of floating point problems, por ejemplo).

En el caso del cohete, al almacenar un número real en las posiciones reservadas para un número entero se quedó sólo con la primera parte del mismo, generando un desbordamiento de enteros.

Well, in this case, when the 16-bit signed integer was used, the conversion from float to integer wrapped around to the beginning again and finally ran into the very familiar integer overflow. Riight, so back to the rocket story.

El sistema de control detecta que los datos son inconsistentes, trata de arreglar el problema y (aquí viene el segundo problema) lanza el sistema secundario que ejecuta exactamente el mismo código.

But wait a minute, there might be a saving chance! The system is designed to have a backup, standby system, which unfortunately, runs the exact same code. It tries the same conversion, gets the same error and just 72 milliseconds later, promptly crashes.

El sistema de control da por bueno el resultado, y el cohete recibe las instrucciones incorrectas.

Sin embargo, si este sistema ya se usaba anteriormente, ¿por qué no había fallado antes? Parece que el problema en este caso era que en las versiones del cohete la velocidad era menor y, por lo tanto, no tenían este problema.

The same software was designed and used successfully on many flights previously, on the Ariane 4 rockets, which were much smaller. But the new Ariane 5 model was designed to fly faster than the systems engineers had planned when that code was originally created.

Finalmente, el código no era necesario después del despegue, así que no debería haber estado ejectutándose, pero para evitar reconfiguraciones en ese momento permitieron que ese código siguiera ejecutándose un poco más, ¡esos 40 segundos!

The worst part? The code wasn’t necessary after takeoff, it was only part of the launch pad alignment process. But sometimes a trivial glitch might delay a launch by a few seconds and, in trying to save having to reset the whole system, the original software engineers decided that the sequence of code should run for an extra… 40 seconds after the scheduled liftoff.