Presentación de RSA en Scientific American

En Martin Gardner, RSA y otros pasatiempos matemáticos cuentan una historia sobre la presentación de RSA en la revista Scientific American (traducida como Investigación y Ciencia por aquí). El matemático martin Gardner tenía una columna sobre pasatiempos matemáticos y en agosto de 1977 presentaba los fundamentos de RSA con un reto a los lectores sobre la factorización de números primos, que es una historia que a veces contamos en clase cuando hablamos de la parte algorítmica de estas cosas.

El desafío consistía en factorizar la clave pública en sus dos factores y emplearlos para descifrar el mensaje. El texto llano es una frase inglesa convertida en un número mediante el procedimiento habitual (a=0, b=1…) elevado a 9007 módulo r. Rivest estimaba que usando el mejor algoritmo de factorización conocido y el más rápido de los ordenadores disponibles (del año 77) serían necesario del orden de 40 cuatrillones de años para resolver el reto.

La cosa tiene su gracia porque, al final, el desafío se resolvió 17 años después (utilizando, eso sí) 600 voluntarios con alrededor de 1600 máquinas calculando durante seis meses.

Puede leerse gratis el principio del artículo traducido en Comunicaciones secretas y el artículo original escaneado en A new kind of cipher that would take millions of years to break.

Buena lectura para estos días de navidad.

Consejos para almacenar las claves

En Do any security experts recommend bcrypt for password storage? y, en particular, en la primera respuesta un buen texto sobre el almacenamiento de claves y los algoritmos adecuados para hacerlo. Se discute sobre Bcrypt y PBKDF2 y se comenta sobre alguno más.

Para este tipo de almacenamiento hoy en día hay que tener en cuenta ataques bastante esotéricos con GPU (procesadores gráficos) y FPGA como herramientas de cálculo masivo de manera muy eficiente. Los nuevos algoritmos tienen que tener en cuenta no sólo la velocidad de cálculo, sino también la cantidad de RAM utilizada y otros parámetros.

Se puede completar la lectura con The Theory que es un enlace directo a la primera respuesta de otra pregunta sobre el tema, con un análisis de las necesidades actuales, ventajas en inconvenientes de las principales soluciones…

La conclusión, en este caso es:

Use bcrypt. PBKDF2 is not bad either. If you use scrypt you will be a “slightly early adopter” with the risks that are implied by this expression; but it would be a good move for scientific progress (“crash dummy” is a very honourable profession)

Que es bastante parecida a la del artículo anterior.

Inyección de SQL basada en la evaluación de enteros en expresiones anidadas

En Exploiting Integer Based SQL Injection in Nested SQL Queries una demostración más de que las cosas que pueden ir mal se encuentran en cualuquier parte.

En este caso se trata de una pregunta SQL anidada que evalúa los parmámetros enteros que se le pasan como parámetro. Y también, cuando evaluamos otras cosas que el sistema de gestión de bases de datos sabe evaluar. Es un proceso bastante manual, claro, pero en los casos en los que no se hace validación de los datos puede permitir conocer cosas sobre la base de datos que no debería.

Cuidado con la gestión de nombres

Dar un curso de desarrollo seguro (y de seguridad en general) es bastante ‘agradecido’ desde el punto de vista de encontrar ejemplos, porque la actualidad siempre nos trae sorpresas.

Estábamos hablando en clase sobre los problemas de los nombres y de tomar decisiones sobre ellos y justo aparece el fallo en git: Vulnerability announced: update your Git clients

The vulnerability concerns Git and Git-compatible clients that access Git repositories in a case-insensitive or case-normalizing filesystem. An attacker can craft a malicious Git tree that will cause Git to overwrite its own .git/config file when cloning or checking out a repository, leading to arbitrary command execution in the client machine. Git clients running on OS X (HFS+) or any version of Microsoft Windows (NTFS, FAT) are exploitable through this vulnerability. Linux clients are not affected if they run in a case-sensitive filesystem.

La negrita la he puesto yo.

Se puede leer también el anuncio en la lista de desarrollo de git, [ANNOUNCE] Git v2.2.1 (and updates to older maintenance tracks) y Git 1.8.5.6, 1.9.5, 2.0.5, 2.1.4 and 2.2.1 and thanking friends in Mercurial land.

Si nos interesa ver el código, al menos a una parte, podemos echarle un vistazo a path: add is_ntfs_dotgit() helper, donde hablan de:

On NTFS (and FAT32), there exist so-called “short names” for backwards-compatibility: 8.3 compliant names that refer to the same files as their long names. As “.git” is not an 8.3 compliant name, a short name is generated automatically, typically “git~1”

Y también a: read-cache: optionally disallow HFS+ .git variants donde se ven las invocaciones a la función añadida y alguna cosa más.

Esta entrada se ha publicado orginalmente en Cuidado con la gestión de nombres.

Ataques cada vez más enfocados

En Watering hole: nuevos términos para ¿nuevos? ataques se habla del nombre que se ha empezado a dar a los ataques dirigidos realizados desde sitios web más o menos comunes (‘watering hole’ sería el bebedero a donde acuden los animales a saciar su sed).

fuente

La analogía sería un sitio web frecuentado por un determinado número de personas, entre las que se encuentra el objetivo. Como se trata de un sitio que seguramente visitaría con frecuencia, relajaría las condiciones de acceso y sería menos precavido.

Ya habíamos hablado de Ataques a objetivos concretos y Puedes estar vigilado. También de los ‘bebederos’, en un ataque a Facebook: Ataques dirigidos: el caso de Facebook.

¿En qué confíamos?

En Un compilador que infecta los binarios hablábamos de la confianza y recuperábamos una lectura clásica sobre el tema de en qué podemos confiar y cómo en algún momento cedemos el control.

Se me había pasado la técnica que propuso David A. Wheeler’s Page on Fully Countering Trusting Trust through Diverse Double-Compiling (DDC) - Countering Trojan Horse attacks on Compilers donde habla de cómo se podría mejorar la confianza en los binarios que generemos, mediante doble compilación diversificada, “Diverse Double-Compiling” (DDC). En el resumen:

In the DDC technique, source code is compiled twice: once with a second (trusted) compiler (using the source code of the compiler’s parent), and then the compiler source code is compiled using the result of the first compilation. If the result is bit-for-bit identical with the untrusted executable, then the source code accurately represents the executable.

Hay un vídeo sobre la PhD Public Defense of Fully Countering Trusting Trust through Diverse Double-Compiling

Hay esperanza. Pero … ¿Estamos dispuestos a pagar el precio de la complejidad añadida?

Algunos datos sobre el uso de ssh

En We scanned the Internet for port 22 un estudio sobre el puerto 22 y su utilización.

Yesterday (Sept. 12) we scanned the entire Internet for port 22 – the port reserved for “SSH”, the protocol used by sysadmins to remotely log into machines. Unlike our normal scans of port 80 or 443, this generated a lot more “abuse” complaints, so I thought I’d explain the scan.

De los resultados, se puede ver:

In other words, the top result of 1,730,887 systems on the Internet show an SSH banner of “SSH-2.0-OpenSSH_4.3”. (Note: this is actually only 60% of the Internet, I’ve got corruption in the files for 40% of the results that I need to fix).

También es interesante ver como hay quien se enfada por recibir este tipo de pruebas y quien anima a realizarlas.

Las claves muy largas también pueden ser problemáticas

Una pregunta frecuente cuando alguien empieza a preguntarse por los temas de seguridad es por qué no poner la contraseña, o lo que sea, más grande para estar un poco más seguros. Normalmente eso puede ser un problema porque mayor tamaño implica más necesidades de cálculo, de almacenamiento…

En Too long passwords can DoS some servers se refieren a un fallo en Django, donde no hay una restricción para el tamaño máximo de las claves y que podría poner a algunos servidores en problemas.

Hay más detalles en Security releases issued.

The default password hasher in Django is PBKDF2, which has the virtue of allowing the complexity of computing the hash to be effectively arbitrarily high, by repeated “rounds” of application before producing the final result. This increases the difficulty of attacks which use brute-force methods to compute the hashes of many possible plaintext values, in hopes of discovering which plaintext password corresponds to a given hashed value.

Unfortunately, this complexity can also be used as an attack vector. Django does not impose any maximum on the length of the plaintext password, meaning that an attacker can simply submit arbitrarily large – and guaranteed-to-fail – passwords, forcing a server running Django to perform the resulting expensive hash computation in an attempt to check the password. A password one megabyte in size, for example, will require roughly one minute of computation to check when using the PBKDF2 hasher.

Interesante.

Por cierto que sobre el tema del ‘hashing’ de contraseñas había un resumen interesante en About Secure Password Hashing.

Algunos enlaces interesantes sobre claves

Primero, un artículo periodístico-‘literario’ donde se intenta justificar las malas contraseñas y por qué la gente hace eso. The Secret Life of Passwords

Llaves

Llaves en Instagram

A continuación tres artículos que tienen bastantes puntos en común; discuten sobre algunas justificaciones que se dan de vez en cuando para imponer ciertas normas de seguridad sobre las claves.

Esencialmente se discuten algunas reglas habituales en la gestión de contraseñas que, según los autores, podrían no ser tan interesantes/útiles en muchos casos.

Traemos también un informe del SANS Institute, con información histórica: [PDF] Password Security– Thirty-Five Years Later.

Y, para terminar,

Ya habíamos hablado de contraseñas, en la versión anterior de este sitio por ejemplo en Claves y usabilidad, Sobre claves y control de acceso en sitios web, La autenticación y las aplicaciones y los espectaculares (desde mi punto de vista) artículos enlazados en Contraseñas, usabilidad y uso que están bastante alineados con los que poníamos al principio.