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.

Otro estudio sobre claves

No creo que el título sea apropiado, sobre todo teniendo en cuenta que ya nos hemos preguntado si el sistema de usuario/clave es el más adecuado para estas cosas pero me gusta guardar estos datos, que nunca se sabe: Survey Reveals How Stupid People are With Their Passwords.

• 4 in 10 respondents shared passwords with at least one person in the past year.

• Nearly as many people use the same password to log into multiple Web sites, which could expose their information on each of the sites if one of them becomes compromised. (A separate recent study revealed that 75% of people use the same password for Social Networking Sites and their email accounts)

• Almost half of all users never use special characters (e.g. ! ? & #) in their passwords, a simple technique that makes it more difficult for criminals to guess passwords. (Yet not all sites support this option of special characters!)

• 2 in 10 have used a significant date, such as a birth date, or a pet’s name as a password – information that’s often publicly visible on social networks.

Además,

Younger people are especially likely to take online security risks. Webroot found that among 18 to 29 year-olds:

• 12 percent have shared a password in a text message (vs. 4 percent overall)

• 30 percent logged into a site requiring a password over public WiFi (vs. 21 percent overall) (Note: This is typically only dangerous when you logon not using SSL — aka HTTPS in your browser)

• Over half (54 percent) have shared passwords with one or more people in the past year (vs. 41 percent of people overall)

The number of Web sites that require an extra layer of security has proliferated, driving careless habits:

• Three quarters (77 percent) of consumers have five or more accounts with online services that require passwords.

• One-third (35 percent) have 10 or more password-protected accounts. Only 10 percent ensure they never use the same password on different accounts.

• Passwords are forgotten occasionally, often or always by over half of consumers (51 percent).

Despite these disturbing figures, consumers still think they are safe, with 50 percent of people saying they feel their passwords are very or extremely secure. That being said, according to the survey:

• 86 percent do not check for a secure connection when accessing sensitive information when using unfamiliar computers.

• 14 percent never change their banking password.

• And 30 percent remember their passwords by writing them down and hiding them somewhere like a desk drawer.

• 41 percent use the same password for multiple accounts.

• Only 16 percent create passwords with more than 10 characters in length.

• Almost half of Facebook users (47 percent) use their Facebook password on other accounts and 62 percent of Facebook users never change their password.

Claves y usabilidad

Dos disciplinas se están abriendo paso en todo lo que se refiere a la seguridad: una aproximación desde una perspectiva económica (¿cuánto cuesta, cuánto vale lo que se protege, es mejor perder un poco y hacer más negocio o estar muy protegido?) como vimos, por ejemplo, en La economía de la seguridad y uno de cuyos principales representantes sería Ross Anderson (Economics and Security Resource Page). La otra es la usabilidad (la seguridad tiene que ver con que las operaciones de seguridad sean, además, las fáciles y sencillas de obtener). Hemos comentado sobre ello en Sobre claves y control de acceso en sitios web, Contraseñas, usabilidad y uso, Redes sociales, interfaces y usabilidad y algún otro.

Por eso me gustó el otro día ver la aproximación inversa: desde el punto de vista de la usabilidad, la aproximación a la reinicialización de claves (cuando se nos olvidan, por ejemplo), en The password reset experience y The truth about passwords. Cualquier practicante de estos temas debería tener muy presentes los consejos (de acuerdo, siempre, al bien protegido) y no sobrecargar a los usuarios con nuestras preocupaciones sobre su seguridad.

Contraseñas de un solo uso

En Contraseñas de un solo uso en Linux donde explica una solución para este sistema operativo basada en el teléfono móvil.

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.

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

Tener claves seguras

Antes de las vacaciones leí en CSRF vulnerability in GMail service sobre un fallo de GMail a la hora de impedir los intentos repetidos de pruebas de claves. El fallo serviría para saber qué usuarios tendrían claves débiles (porque los mensajes son diferentes según la calidad de la clave y si corresponde o no a la clave del usuario). Con la característica adicicional de que, en ese uso, no exigían el CAPTCHA (Vicente Aguilera encontró un eslabón débil).

A la vuelta encontré como Bruce Schneier comentaba en Password Advice los consejos sobre qué hacer y qué no hacer basándose en Gmail flaw shows value of strong passwords donde se comentaba también el fallo descubierto por Aguilera:

According to Aguilera’s new security alert, Google allows anyone with a Gmail account to guess another Gmail user’s password 100 times every two hours, or 1,200 times per day. No “captcha” keeps hacker bots from guessing passwords in this way. Worst of all: If a hacker controls, say, 100 Gmail accounts, 120,000 guesses can be made per day. Because Gmail accounts are free, many hackers control far more than 100 accounts, of course.

No vamos a hablar de los consejos, pero algunas lecciones: los más grandes cometen errores, se puede atacar los eslabones débiles, y mucho cuidado con la realimentación que proporcionan nuestros programas (ya hablaba de ello Tanenbaum en el libro de Sistemas Operativos y ahí seguimos).

Variaciones sobre las claves

Un artículo sobre las claves en Do Strong Web Passwords Accomplish Anything? (pdf) donde se sugiere que a lo mejor es suficiente con claves más cortas de lo que solemos pensar y que valdría la pena incidir en el aspecto de los identificadores (en lugar del dni, o alguno predefinido permitir a los usuarios elegir el suyo). Creo que las claves conviene que sean fuertes y también que el identificador pueda ser elegido por los usuarios (más que nada porque, al final, en algunas aplicaciones -¿la de los puntos de tráfico?- hay gente que ni siquiera sabe que las tiene disponibles y los ‘malos’ saben perfectamente cómo intentar acceder a tus datos).

Siguiendo con el capítulo de ‘heterodoxias’ variadas, el experto en ergonomía (usabilidad) ‘emitía’ una de sus ‘alert box’ sobre el tema de ocultar la clave cuando la estamos tecleando: Stop Password Masking. Esencialmente decía que enmascararla puede favorecer la seguridad pero el precio que se paga desde el punto de vista del usuario es alto, especialmente en dispositivos móviles (doy fe). Bruce Schneier en un primer momento se mostró de acuerdo (The Problem with Password Masking) pero luego se lo pensó mejor y matizó (que es, casi siempre, la manera correcta de enfrentarse a las cosas): The Pros and Cons of Password Masking. Básicamente, depende del contexto: tal vez habría que pensarlo un poco antes de enmascarar la clave y ver cómo y dónde se va a usar.

Es como esas medidas que a veces se aplican sin pensarlo mucho: cambiar la clave cada X tiempo, obligar a que sea de determinada forma, …

Sobre el almacenamiento de claves

La autentificación y la identificación son temas que dan mucho de sí. Sin embargo en este caso nos quedamos con un objetivo más modesto que es el almacenamiento de claves. Lo discute el autor de Enough With The Rainbow Tables: What You Need To Know About Secure Password Schemes y explica unos cuantos sistemas con sus ventajas y debilidades. Descubrimos que el más usado (y hasta recomendado a veces) es el más débil y (como casi siempre) que hacer las cosas bien es más difícil de lo que parece.

Cuando se usan datos personales como clave

Alguien puede sacar partido de ello. El caso reciente es la aplicación para comprobar el saldo puntos de la DGT: para solicitar la clave inicial basta con el NIF/NIE y la Fecha de Expedición. Después se pone un correo electrónico y nos envían la clave.

No es que la fecha de expedición sea fácil de adivinar, pero tampoco es un dato imposible de conseguir (no he comprobado a ver si hay un límite de intentos), junto con el identificador. Seguramente sería más razonable enviar la clave por correo a la dirección del carnet de conducir: más lento, pero costaría algo más de trabajo robarla.

Lo cuentan en Tráfico desprotege el saldo de puntos de los conductores, que directamente lo sacaron de DENUNCIA DE LA AEPD Poca seguridad en la consulta del saldo de puntos.

El eterno problema de la comodidad frente a la seguridad.