El otro día mi amigo Gabriel del Molino (@gmolino) me invitó a dar una charla a sus alumnos de un curso de formación para desempleados donde reciben una panorámica de desarrollo web. La propuesta era abierta pero estaban especialmente interesados en temas de seguridad.

Como se trataba de una sesión única y no era plan de entrar en detalles técnicospreferí presentar algunos principios y completarlo con una introducción motivadora, algunas ideas sobre identificación y autentificación y, finalmente, recordar que nuestro trabajo casi siempre tiene que ver con la economía y con las personas.

Dejo aquí la presentación por si a alguien puede servirle de algo.

Se habla con mucha frecuencia de la autentificación, y de los diversos sistemas disponibles, pero no hay que olvidar que si queremos estar seguros no podemos confiar sólo en ellos. Cada vez más tenemos que utilizar la información adicional de la que dispongamos para estar seguros de que el usuario es quién dice ser.o

En Trust, but Verify: Authentication Without Validation Is Naïve daban algunas ideas sobre ello.

Primero, alguna paradoja: es más probable que las preguntas de seguridad las responda adecuadamente un atacante que el legítimo propietario de la cuenta:

Gartner research, however, found that users fail to answer their knowledge-based questions 15–30 percent of the time, while fraudsters answer correctly 60 percent of the time. Malicious actors often find this information on social networks or through phishing schemes.

Si confiamos en dispositivos como los teléfonos para la validación también nos podemos encontrar problemas:

his practice has shifted to mobile phones, with OTPs being sent as text messages. However, mobile malware can intercept these messages and forward them to fraudsters.

Y, desde luego, la biometría también tiene sus problemas:

… which has led to the exponential growth of fingerprint reader-enabled devices. It didn’t take long, however, for cybercriminals to circumvent this technology

¿Entonces? Como decíamos, hay que ser capaces de utilizar la información extra de la que dispongamos. Por ejemplo, sobre el comportamiento, y otros identificadores.

Parece que el tema de la generación informática de números aleatorios ha ganado interés en los últimos años. Hoy lo decimos por el contenido de A Brief History of Random Numbers donde se habla del tema desde una perspectiva histórica: la aleatoriedad es algo muy abundante en la naturaleza, pero no es sencilla de obtener con herramientas humanas:

The randomness so beautifully and abundantly generated by nature has not always been easy for us humans to extract and quantify.

Los primeros intentos informáticos parecen datar de los años 40, de la mano de RAND Corporation:

… the modern world demanded a lot more random numbers than dice or yarrow stalks could offer. RAND Corporation created a machine that would generate numbers using a random pulse generator.

Posteriormente hubo algunos intentos más, hasta que surgió la idea de los generadores de números seudoaleatorios (pseudorandom number generator, PRNG). Se comentan algunas de las aproximaciones algorimicas y también curiosidades como LavaRand, diseñado por Silicon Graphics, y basado en un par de lámaras de lava y una cámara tomando imágenes. Por cierto, el método sigue vigente, según nos contaban en 10% of the Internet Is Encrypted with Lava Lamps, hablando del proveedor Cloudflare.

También se comenta sobre iniciativas como los servicios proveedores de números aleatorios, como Random.org y cómo, finalmente, Intel añadió en 1999 un generador en su chipset i810 para servidores, basado en el ruido térmico de los procesadores:

In 1999, Intel added an on-chip random number generator to its i810 server chipset. Finally, new servers had a good local source of randomness from thermal noise — a true random number generator (TRNG).

Sin embargo, no hay que olvidar que no sólo necesitamos números aleatorios, sino que los necesitamos a velocidad adecuada; y no sólo necesitamos números seudoaleatorios, sino que necesitamos números seudoaleatorios seguros (Aleatoriedad y juego en línea. No sólo para juegos, claro).

Finalmente, se habla (habiendo pasaro por otros temas) de las discusiones sobre qué esquemas de generación utilizar, cuando hablamos de programas con la seguridad en mente, o simplemente de otros usos menos comprometidos.

Personalmente, hace algún tiempo que dejé de dar consejos sobre la creación de contraseñas. Creo que la solución para cualquier usuario es utilizar un gestor de contraseñas y eso es lo que recomiendo cuando alguien me pregunta. O cuando med dejan decirlo sin que me pregunten. También digo, si alguien se empeña en crearlas y recordarlas que lo mejor es que sean largas (desde luego, más de 10 o 12 caracteres, en este momento).

Las normas de creación de contraseñas pueden tener sentido si se hacen bien, pero es bastante fácil que hagamos recomendaciones malas (he visto algunas horribles y otras que, en lugar de ayudarnos a mejorar nos perjudican) y que, aunque sean buenas, se sigan mal.

De ello hablaba Jeff Atwood en Password Rules Are Bullshit

Desde el otro lado, los consejos que da son:

• Las reglas son una basura
• Fuerza una longitud mínima (en Unicode)
• Verifica que no se utilizan contraseñas comunes
• Verifica que tienen una mínima diversidad (entropía)
• Verifica casos especiales (usuario, correo, … No deberían ser contraseñas)

Interesante.

En una bitácora como esta, que no sólo no es de actualidad sino que suele traer temas con bastantes meses, no se si tiene mucho sentido traer estas cosas pero me gusta guardarlas para tenerlas en algún sitio recopiladas.

Por eso traigo Announcing the first SHA1 collision que habla de una colisión en un sistema de firma (hash). La idea de estos sistemas es sencilla: no debería ocurrir que dos ‘mensajes’ diferentes produzcan el mismo resumen. En este caso anunciaban una forma de generar una colisión para el algoritmo SHA1. Para el común de los mortales esto significa, esencialmente, que ya podemos ir pensando en dejar de usarlo (si es que lo hacíamos). También es un recordatorio de que los ‘estándares’ que alguien nos recomendó en algún momento van quedando obsoletos y que no podemos dejarnos llevar por la costumbre y la comodidad.

A collision occurs when two distinct pieces of data—a document, a binary, or a website’s certificate—hash to the same digest as shown above. In practice, collisions should never occur for secure hash functions. However if the hash algorithm has some flaws, as SHA-1 does, a well-funded attacker can craft a collision.

En esa entrada nos recomendaban utilizar SHA-256 y SHA-3.