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?

Los números aleatorios son una componente importante en cualquier desarrollo que tenga que ver con la seguridad. En Intel® Digital Random Number Generator (DRNG) Software Implementation Guide podemos leer la documentación del generador de Intel y algunos comentarios interesantes.

Ya habíamos hablado de Números aleatorios y seguridad y las consecuencias de usar números aleatorios de calidad insuficiente en Algunas debilidades de HTTPS.

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.

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.

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 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.

• Dinei Florencio, Cormac Herley, and Paul C. van Oorschot, An Administrator’s Guide to Internet Password Research
• Dinei Florêncio, Cormac Herley, Baris Coskun, [PDF] Do Strong Web Passwords Accomplish Anything?
• Dinei Florencio, Cormac Herley, and Paul C. van Oorschot, [PDF] Password Portfolios and the Finite-Effort User: Sustainably Managing Large Numbers of Accounts

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,

• It Gets Worse: The Newest Sony Data Breach Exposes Thousands Of Passwords Donde podemos leer: Included in the newest data dump is a file directory titled “Password,” which includes 139 Word documents, Excel spreadsheets, zip files, and PDFs containing thousands of passwords to Sony Pictures’ internal computers, social media accounts, and web services accounts. Most of the files are plainly labeled with titles like “password list.xls” or “YouTube login passwords.xlsx.”

• Why password managers (sometimes) fail

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.