Más datos sobre claves

En The science of password selection un (otro) informe sobre las claves que se obtienen de diversas maneras de usuarios reales en la red.

De mis notas.

¿Cómo eligen las claves los usuarios?

En este caso los datos vienen de varias fuentes:

The data I’m going to analyse comes from a variety of sources including the Sony and Gawker breaches I referenced in the previous post as well as other LulzSec releases including pron.com and a collection of their random logins.

Se usan nombres (un 14% de claves, derivadas de nombres):

I also suspect they feature heavily when someone reaches into the recesses of their mind to come up with a password. Now of course the name is not necessarily the name of the account holder; it could be a spouse, the kids or even the family dog. Furthermore, it could be a first name, a middle name or a last name.

Un 25% son palabras del diccionario (incluyendo la palabra ‘password’)

A huge 25% of passwords are derived directly from dictionary words. In
reality, it’s probably somewhat higher than this as my dictionary had less
than a couple of hundred thousand words. And they’re all only English
language.

Top among the dictionary favourites are:

password (oh dear)
monkey
dragon

Las claves numéricas tienen en su mayoría (83%) cuatro, seis u ocho dígitos, pero hay un buen número de longitud uno, por ejemplo.

Why is this interesting? Well firstly, within a spread of numeric password lengths which range from 1 (yes, 1, and there’s a heap of ‘em) to 21, 83% of the passwords are either four, six or eight digits long. Is this a propensity for even numbered password lengths or something else?

Los de cuatro podrían corresponder al PIN del cajero automático.
Los de seis serían fechas donde el año tiene dos cifras.
Los de ocho serían fechas con el año completo.

Las claves con dos palabras repetidas (blabla) serían menos del 3%, pero es un patrón que utiliza la gente.

También hay quien utiliza frases cortas del estilo de: ‘dejameentrar’ o similares.

Naturalmente, he hecho una selección según mis gustos y sesgos, pero vale la pena leerlo todo para hacerse una idea.

Las claves de Gawker

Me da un poco de pereza estos temas de las claves (además ya publicamos el otro día un enlace a unos artículos que tratan el tema con más profundidad): cada vez que alguien consigue robar claves de un sitio, empiezan a aparecer los ‘contables’ haciendo análisis numerológicos, listas de consejos que nadie seguirá y todas esas cosas. Aúna así, me gustó leer Why You May Want to Avoid Non-ASCII Characters in Your Passwords que habla de la explicación más detallada, en Gawker Password Management Q/A. Un problema de compatilidad hacia atrás, utilización de métodos poco seguros (y que no manejan los caracteres internacionales) y mala gestión de los cambios parecen los responsables del problema.

Para completar, en The Gawker hack: how a million passwords were lost: para conseguir las claves se habría utilizado un ataque de fuerza bruta a un sistema auxiliar, una búsqueda de claves de sitios más ‘interesantes’ en sistemas de comunicación interna, y a partir de allí el robo de las claves en sí.

Sobre la contabilidad, un ejemplo en Brief Analysis of the Gawker Password Dump.

Quede aquí, a título de inventario.

Cómo no almacenar claves en iOS

No me gustan mucho los artículos en negativo: al final, en algunas ocasiones, uno no se entera de qué es lo que realmente tiene que hacer (la negación de la negación no siempre se hace bien, o se interpreta adecuadamente).

En How Not to Store Passwords in iOS un artículo sobre la maquinita de moda y la gestión de claves en ella. Concretamente con el ejemplo del tratamiento de claves por parte de la aplicación para actualizar WordPress, que no cononocía.

El aparato tiene un lugar para almacenar las claves de manera adecuda, keychain services y los desarrolladores no la utilizaban:

Mobile development brings both familiar and new challenges for creating secure applications. The iOS platform provides a number of strong security features with the Keychain and protection attributes introduced in iOS 4.0. As usual, it is up to developers, development teams, and security professionals to make sure that user data is handled securely and appropriate APIs are used correctly.

¿Nos suena? (¿Los desarrolladores utilizan las ayudas en seguridad?).
Si nos preocupa la seguridad de los sistemas que desarrollemos una de nuestras primeras tareas debería ser buscar la información sobre qué ayudas nos proporcionan para no meter la pata y poder utilizarlas adecuadamente.

Sobre claves y control de acceso en sitios web

En Contraseñas, usabilidad y uso hablamos del artículo, pero en Economic Considerations of Website Password Policies añaden los enlaces a cuatro entradas de los autores del estudio donde se extienden en algunos aspectos:

Passwords in the wild, part I: the gap between theory and implementation, con comentarios generales sobre las políticas de los sitios y los resultados del artículo.

Passwords in the wild, part II: failures in the market, comentando sobre el tipo de sitios examinados (y sin examinar).

Passwords in the wild, part III: password standards for the Web es la parte que me ha parecido más interesante, porque aporta información sobre los estándares y prácticas más o menos establecidas en la industria. Para releer con cuidado.

Passwords in the wild, part IV: the future donde, como el título indica, especulan sobre el futuro.

Definitivamente, si no habíamos leido el artículo ([PDF] “Where Do Security Policies Come From?), un buen repaso en un formato más accesible.

Actualización 21/I: quede para mi vergüenza el error de arriba. Evidentemente, nos referimos al artículo [PDF] The password thicket: technical and market failures in human authentication on the web. que es sobre lo que comentan los autores.

¿Cada cuánto cambiar la clave?

Una aportación al tema de Bruce Schneier, Changing Passwords:

So in general: you don’t need to regularly change the password to your computer or online financial accounts (including the accounts at retail sites); definitely not for low-security accounts. You should change your corporate login password occasionally, and you need to take a good hard look at your friends, relatives, and paparazzi before deciding how often to change your Facebook password. But if you break up with someone you’ve shared a computer with, change them all.

Buenas prácticas sobre claves y bloqueo de cuentas

Por alguna casualidad, escuché el otro día el [mp3] OWASP 76 podcast, con Bill Cheswick sobre claves, bloqueo de cuentas y esas cosas. Estaba pensando que me había parecido bastante interesante y que debería poner un resumen por aquí cuando encontré Password and Account Lockout Better Practices que me ahorra el trabajo:

  • Bloquear la cuenta después de 3, 4 o 5 intentos
  • Utilizar un tiempo de bloqueo corto
  • Asegurarse de que errores repetidos (el mismo intento más de una vez)
    no cuentan para el bloqueo
  • Utilizar personas de confianza (previamente establecidas, por ejemplo
    la pareja de alguien) para los procesos de reestablecimiento de la clave
    (se ahorran procedimientos más complicados y costosos)
  • Hacer que los identificadores de usuario sean difíciles de conocer o
    adivinar
  • Utilizar un servicio de autentificación estándar, para no reinventar la
    rueda en cada nueva aplicación

Otro día más sobre claves.