Cualquiera sabe que cuando nos encontramos con una ‘normativa’ de contraseñas lo consideramos directamente una molestia: muchas veces chocan con nuestras propias costumbres y reaccionamos mal. A veces, si tiene que tener un símbolo, ponemos siempre el mismo, si es un número añadimos un uno al final y cosas así… Eso cuando las normas no están directamente mal porque hacen la contraseña peor en lugar de mejor (ponga un caracter de este tipo en la posición X -exagero, pero seguro que han visto normas similares-). Recordar, por ejemplo, Las políticas de creación de contraseñas son contraproducentes.

Y en eso estamos mientras los que saben de estas cosas nos dicen algo ligeramente diferente: Stringent password rules lower risk of personal data breaches.

En particular, si pedimos para nuestro servicio una contraseña más larga y complicada, disuadiremos a los usuarios de reutilizarla en otras partes:

“We found that requiring longer and more complicated passwords resulted in a lower likelihood of password reuse,” the authors write in the paper, Factors Influencing Password Reuse: A Case Study.

El estudio se realizó analizando normativas de contraseñas de 22 universidades estadounidenses y el resultado fue claro: ser más exisgentes reducía el riesgo de ataques a datos personales dentro de las universidades.

The findings were clear: Stringent password rules significantly lower a university’s risk of personal data breaches.

“Our paper shows that passphrase requirements such as a 15-character minimum length deter the vast majority of IU users (99.98 percent) from reusing passwords or passphrases on other sites,” they write. “Other universities with fewer password requirements had reuse rates potentially as high as 40 percent.”

Por lo tanto, el consejo sería aumentar el tamaño exigido de las contraseñas, prohibir el nombre del usuario dentro de las mismas y añadir autentifiacción multi-factor.

The authors offer the following recommendations to safeguard passwords:

Increase the minimum password length beyond 8 characters. Increase maximum password length. Disallow the user’s name or username inside passwords. Contemplate multi-factor authentication.

A mi me convence que esto pueda ser efectivo aunque me recuerda a esos mecanismos de seguridad que ponemos para hacer que se fijen en otros: no es que añadan seguridad, es que muestran la falta de seguridad de los demaś.

También me recuerda un estudio, que no he sido capaz de encontrar de hace años donde se contraponía el deseo de que usen tu sitio (Amazon era el ejemplo, si norecuerdo mal) frente a la obligación de que utilicen tu sitio (el ejemplo eran los sitios gubernamentales donde el ciudadano tiene no puede evitar ir y, por lo tanto, podían ser más exigentes con medidas molestas como la de la longitud de la contraseña; el caso de las universidades sería similar).

Durante el año pasado se ha hablado mucho de machine learning e inteligencia artificial. Traemos aquí un artículo sobre identificación de programadores, que podíamos leer en Even anonymous coders leave fingerprints.

La idea es sencilla: tenemos código de varios programadores (por ejemplo, de sus repositorios públicos) y tenemos un código fuente del que desconocemos la autoría. En el artículo nos cuentan que podríamos identificar al autor con una probabilidad bastante buena de acertar.

El resultado se presentó en una conferencia de seguridad y utilizaba machine learning (aprendizaje automático) para des-anonimizar los autores de algunas muestras de código.

At the DefCon hacking conference Friday, the pair will present a number of studies they’ve conducted using machine learning techniques to de-anonymize the authors of code samples.

Podría utilizarse para dirimir temas relacionados con la copia (el plagio que también ha estado de moda desde el verano). También podría preocupar a programadores que contribuyen a proyectos de software libre.

Their work, some of which was funded by and conducted in collaboration with the United States Army Research Laboratory, could be useful in a plagiarism dispute, for instance, but also has privacy implications…

Curiosamente, los programas se hacen en lenguajes estructurados donde la sintáxis es más o menos rígida, no hay mucha variedad de palabras para elegir… Pero aún así, hay características únicas para cada persona que programa.

Think of every aspect that exists in natural language: There’s the words you choose, which way you put them together, sentence length, and so on. Greenstadt and Caliskan then narrowed the features to only include the ones that actually distinguish developers from each other …

Por ejemplo, la estructura del código

Their technique is akin to prioritizing someone’s sentence structure, instead of whether they indent each line in a paragraph.

Aparentemente, estos aspectos sobrevivirían incluso a algunas de las técnicas de ofuscación del código empleadas habitualmente.

… have found that some off-the-shelf obfuscation methods, tools used by software engineers to make code more complicated, and thus secure, aren’t successful in hiding a developer’s unique style.

Y, claro, el estilo se desarrolla con el tiempo y la experiencia:

For example, they have found that experienced developers appear easier to identify than novice ones. The more skilled you are, the more unique your work apparently becomes.

También contribuye si el problema que se va a resolver es más complicado.

Similarly, they found that code samples addressing more difficult problems are also easier to attribute. Using a sample set of 62 programmers, who each solved seven “easy” problems, the researchers were able to de-anonymize their work 90 percent of the time. When the researchers used seven “hard” problem samples instead, their accuracy bumped to 95 percent.

Interesante.

Me gustó leer Python and cryptography with pycrypto] porque es una mínima guía sobre criptografía en Python que incluye, el uso de funciones hash, el uso de algoritmos de cifrado, y el uso de algoritmos de clave pública.

Para los que no somos criptógrafos (la mayoría no lo somos) tener una chuleta que nos de las pistas mínimas para cifrar y descifrar algún documento o la información que sea necesaria es fenomenal para no tener que navegar por la documentación. Si, además, viene con código de ejemplo, mejor todavía.

En este caso, ambas cosas están disponibles, los conceptos mínimos y los míni-ejemplos con código en Python.

Traemos hoy una guía sobre control de acceso. Se trata de Approaching Access Control on the Web y nos proporciona una panorámica de las distintas aproximaciones para el control de acceso en la web.

Prometía hablar más de estos temas, pero hasta ahora no ha habido novedades.

En Email encryption is here! Use STARTTLS everywhere! nos hablan de la inciativa de la Electronic Frontier Foundation sobre el uso de STARTTLS everywhere!. Se trata de un mecanismo de cifrado basado en la infraestructura (esto es, las máquinas se conectan entre sí utilizando protocolos cifrados) y que, por lo tanto, es sencillo de utilizar por parte de los usuarios. No es tampoco perfecto, puesto que no se trata de un sistema de cifrado entre receptor y emisor, pero es un compromiso suficientemente bueno, dada la dificultad de otros métodos (¿alguien ha probado a enviar correo cifrado alguan vez?).