Hay una cierta tradición de hacer listas de ‘verdades’ que los programadores creen sobre determinados aspectos (nombres, tiempo, fechas, …) y que no tienen por qué se ciertas. Típicamente tienen que ver con temas culturales y de internacionalización, que no son siempre tenidos en cuenta por los desarrolladores habituales. Recientemente podíamos leer Falsehoods Programmers Believe About Names – With Examples que nos trae de nuevo el tema de los nombres, y al que vale la pena echar un vistazo.

Creo que puede ser un texto interesante incluso para personas que no programan, por lo que se puede aprender de otras culturas y formas de hacer las cosas. Para desarrolladores, es posible que alguna vez tengan que enfrentarse a estos dilemas.

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!