Algunos administradores que pueden hacerlo (seguramente, los mismos que pueden obligarnos a cambiar de contraseña, como contábamos en Los cambios frecuentes de contraseña son contraproducentes creen que añadir una restricción a nuestra contraseña indicando que contenga una cifra y un caracter especial (o variaciones similares) mejora las contraseñas. Lo cierto es que, si permitimos estos caracteres en las claves puede que mejoren (siempre que no se hagan substituciones obvias: l por 1, e por 3, …). Pero siobligamos a que estén, le estamos dando pistas a los ‘malos’: pueden hacer búsquedas en el espacio de claves, poniendo menos alternativas en algunas posiciones (el caso más delirante, que he visto en un par de sitios es ‘forzar’ a que esos caracteres estén en determinadas posiciones). Sin olvidarnos de que cuando eso contraviene nuestras propias costumbres en la generación de contraseñas, tenemos la receta segura para que no la recordemos, o la hagamos peor para estar seguros de recordarla.

De eso hablaban en How Password Constraints Give You a False Sense of Security y yo lo traigo aquí para animar a tantos y tantos administradores a no ser creativos en estas cosas.

Hace un poco de numerología con lo que ahorraría un hipotético atacante sabiendo que tiene que haber, digamos, un dígito:

Assume they can test about 31 billion passwords per second. Cracking their way through your reasonably complicated eight-character password could take, at most, 212,903 seconds. That’s 3,548 minutes, or roughly two and a half days.

Now, let’s talk about constraints for a minute. Assume that the service you’re using requires you to have an eight-character password. Abrams notes that takes 70.6 trillion passwords out of the mix, since every password from a single character long to seven character long is now invalid. That saves the cracking tool a whopping 2,277 seconds, or nearly 38 minutes. That’s not too bad.

Vale la pena leer el resto de argumentos numéricos pero, al final, la conclusión es que lo mejor es que la contraseña sea más larga, incluso en sistemas con restricciones.

Instead of worrying about the best way to make your shorter password harder to guess or brute-force, Abrams advises that it’s a lot better to pick a longer password, because even if a service has password constraints, they’ll have much less of an impact: […]

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