En seguridad informática parece que vivimos el día de la marmota: los temas vuelven sistemáticamente, de tiempo en tiempo. Hoy, los avisos de seguridad y cómo la gente los ignora. Nos lo contaban en People ignore software security warnings up to 90 percent of the time.

Decimos de la gente pero, en realidad, probablemente la culpa sea de los que diseñan los sistemas: o avisan de cosas poco importantes, o cuando no es apropiado (¿alguien recuerda cuando configuró su teléfono o su portátil y empezó a pedirle cosas absurdas cuando lo que en realidad queríamos era volver a estar conectados y trabajando?)

Software developers listen up: if you want people to pay attention to your security warnings on their computers or mobile devices, you need to make them pop up at better times.

Según el estudio que se comenta, uno de los problemas fundamentales es que los avisos llegan cuando la gente está concentrada haciendo otra cosa:

… finds the status quo of warning messages appearing haphazardly—while people are typing, watching a video, uploading files, etc.—results in up to 90 percent of users disregarding them.

Algunos datos, el 74 por ciento de la gente ignora un mensaje de seguridad que aparece cuando estamos cerrando una ventana, y un 79 por ciento no presta atención a los mensajes mientras vemos un vídeo.

For example, 74 percent of people in the study ignored security messages that popped up while they were on the way to close a web page window. Another 79 percent ignored the messages if they were watching a video. And a whopping 87 percent disregarded the messages while they were transferring information, in this case, a confirmation code.

¿Cuándo sería un momento más apropiado? Aparentemente, cuando tenemos momentos de espera o de actividad menor: después de ver un vídeo, mientras se carga una página web, después de utilizar un sitio web…

people pay the most attention to security messages when they pop up in lower dual task times such as:

After watching a video

Waiting for a page to load

After interacting with a website

Seguimos con las contraseñas. En esta ocasión un artículo que ya tiene un par de años, pero que nos avisa de lo peligroso que puede ser obligar a cambiar frecuentemente de contraseña. Ya lo he dicho otras veces pero mi consejo es cambiarlas de vez en cuando, por ejemplo, después de un viaje de vacaciones donde hemos podido incurrir en prácticas de riesgo (WiFis y ordenadores desconocidos, por ejemplo).

En Frequent password changes are the enemy of security, FTC technologist says. En este caso la experta es Lorrie Cranor y habla de su periodo como responable de tecnología de la Comisión Federal de Comercio y los consejos que allí se daban sobre el tema cuando llegó.

Primero, el cambio frecuente de contraseñas es un consejo habitual que está siendo contínuamente rechazado por los experimentos y estudios que se realizan y, además, hay quien lo lleva a la práctica con cambios excesivamente frecuentes.

… Cranor found the advice problematic for a couple of reasons. For one, a growing body of research suggests that frequent password changes make security worse. As if repeating advice that’s based more on superstition than hard data wasn’t bad enough, the tweet was even more annoying because all six of the government passwords she used had to be changed every 60 days.

¿Qué hace la gente cuando se le piden los cambios? Típicamente, añadir un número secuencial a su contraseña:

By studying the data, the researchers identified common techniques account holders used when they were required to change passwords. A password like “tarheels#1”, for instance (excluding the quotation marks) frequently became “tArheels#1” after the first change, “taRheels#1” on the second change and so on. Or it might be changed to “tarheels#11” on the first change and “tarheels#111” on the second. Another common technique was to substitute a digit to make it “tarheels#2”, “tarheels#3”, and so on.

Y la consecuencia es que los ‘malos’ pueden programar eso en sus descubridores de contraseñas sin demasiados problemas:

The researchers used the transformations they uncovered to develop algorithms that were able to predict changes with great accuracy. Then they simulated real-world cracking to see how well they performed. In online attacks, in which attackers try to make as many guesses as possible before the targeted network locks them out, the algorithm cracked 17 percent of the accounts in fewer than five attempts. In offline attacks performed on the recovered hashes using superfast computers, 41 percent of the changed passwords were cracked within three seconds.

Cuidado con los consejos que damos.

Lo decimos con frecuencia por aquí: cuando uno no tiene muy claro qué hacer con respecto a algún asunto lo mejor es mirar normativas, regulaciones, costumbres, lo que hay en el mercado y, claro, lo que hacen los demás.

Hace diez años nacieron dos proyectos relacionados con este tema, uno era el Building Security In Maturity Model (BSIMM) y el otro era Software Assurance Maturity Model. El segundo parece que está abandonado, pero el BSIMM publicó recientemente su último informe y nos enterábamos por BSIMM9: A Decade of Software Security Science de que había alcanzado su décimo aniversario.

El BSIMM se trata de un proyecto basado en observar y medir las mejores prácticas de seguridad del software en las empresas cubriendo en su última versión hasta 120.

The Building Security In Maturity Model (BSIMM) project turned ten this year, with ten years of careful observation of the best software security practices in real companies. BSIMM9, the ninth iteration of the report, describes the software security initiatives of 120 firms in detail.

Estamos hablando de empresas como Adobe, Alibaba, Bank of America, NVIDIA, Lenovo, Cisco, y muchas otras.

Una vez que se tiene esa información, una empresa puede medirse frente a otras y así determinar de qué debería preocuparse primero. Se hace con 116 actividades de seguridad agrupadas en doce prácticas dentro de cuatro dominios: gobernanza, inteligencia, desarrollo y despliegue (una de ellas, por cierto, la formación, dentro del dominio de la gobernanza).

Using the data we gather, we score the organization’s existing efforts in 116 specific software security activities organized into twelve practices. We can directly compare a particular firm’s measurement to the rest of the BSIMM population and draw important conclusions about software security maturity in the firm.

Muy interesante y ¡feliz aniversario!

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.