El impacto de las mejoras de usabilidad en la seguridad de un producto

contraseñas

Hace ya unos años Facebook anunció que empezaría a aceptar versiones ligeramente distintas (EN) de nuestro email y nuestra contraseña a la hora de permitir acceder a la cuenta.

A saber, podremos loguearnos si:

  • Metemos el usuario y la contraseña adecuadamente: Obvio :). Si nuestro usuario es cuenta@gmail.com y nuestra contraseña es c0Ntr4s3ñ4, y lo metemos correctamente, entraremos como es de esperar en la cuenta.
  • Metemos bien el usuario y en la contraseña la primera letra o todas las letras están en mayúscula: Algo que el sistema de verificación entiende que puede ser debido a fallos del propio teclado (en móviles suele pasar que en un input por defecto el primer carácter que tecleemos lo mete como mayúscula), o porque tenemos el Bloq. Mayús activo sin darnos cuenta. En el caso anterior, combinaciones de cuenta@gmail.com y C0Ntr4s3ñ4 o C0NTR4S3Ñ4 nos dejarán loguearnos igualmente, pese a que no sean exactamente correctas.
  • Metemos bien el usuario y en la contraseña intercambiamos mayúsculas por minúsculas: De nuevo, debido supuestamente al Bloq. Mayús. Volviendo al ejemplo anterior, si colocara C0nTR4S3Ñ4 Facebook me dejaría pasar.
  • Metemos bien el usuario y en la contraseña incluimos un carácter extra no contemplado: El caso más habitual, y que al menos a mi, por la forma que tiene mi teclado, me pasa mucho, es que en vez de darle al Intro le doy al botón de la cejilla (ç), o le doy a los dos a la vez (están pegados), pudiendo afectar a mi contraseña: Ejemplo: c0Ntr4s3ñ4ç.
  • Metemos ligeramente mal el usuario y bien la contraseña: Si en vez de teclear cuenta@gmail.com pongo cuenta@gmil.com o combinaciones parecidas, Facebook me dejará pasar.
  • Metemos el usuario y la contraseña con un límite de combinaciones anteriores: Es decir, que todo lo anterior podría estar unido, de forma que por ejemplo metiera cuenta@gmil.comç (dos errores)C0Ntr4s3ñ4ç, incluso mezclándolos entre sí (un error por ejemplo en el user y otro en la contraseña).

La razón es que, como habrá visto, son errores que fácilmente cualquiera de nosotros podemos cometer. Y la duda está entonces en saber qué porcentaje de usabilidad ganamos a cambio de qué porcentaje de seguridad perdemos, habida cuenta de que realmente lo que estamos ofreciendo a un posible interesado en robar nuestra cuenta son varios pares usuario/contraseña funcionales.

Aquí viene la parte interesante. A lo largo de estos últimos años tanto periodistas ampliamente reputados como Emil Protalinski (EN) como cracks de la talla de Chema Alonso (ES) se han pronunciado al respecto alertando de los peligros que tiene tomar medidas de este tipo.

Y hasta cierto punto tienen razón. Pero siempre y cuando se ejecuten de la manera oportuna, como veremos, obtenemos un sistema mucho más usable sin apenas perder seguridad.

La dosis de usabilidad/seguridad adecuada

Para ello tengo que hacer mención al estudio que el año pasado Thomas Ristenpart, profesor de la Universidad de Cornell, junto con su equipo, realizaban, y cuyo paper enlazo por estos lares (EN/PDF).

El objetivo buscado era conocer los errores más habituales que el usuario comete a la hora de meter una contraseña en un formulario, y fue presentado en el Simposio de Seguridad y Privacidad del IEEE con algunos resultados más que interesantes.

Partieron de un universo de 100.000 claves distintas para llegar a los errores que anteriormente hemos comentado: Dejar mayúsculas activadas, escribir con mayúscula la primera letra o añadir una letra sobrante al final. Hay otros no tan comunes, como intercambiar dos letras, que se quedaron fuera de la muestra.

Y como el tema daba para largo, llegaron a un acuerdo con Dropbox, que les permitió analizar las meteduras de pata que cometieron los usuarios de este popular servicio en 24 horas. ¿El resultado? Un 3% (de usuarios legítimos, ojo) fallaron en el primer intento.

Esto supone como mínimo un 3% más de peticiones al servicio, ergo un 3% más de gasto para la compañía. Sin olvidar la molestia de cara al usuario.

Sin estas medidas, por tanto, perdemos un 3% de usabilidad, pero, ¿cuánto ganamos de seguridad?

Para ello realizaron otro estudio en el que, dado un usuario y contraseña específicos, en un servicio que ya contemplaba las medidas de usabilidad anteriormente citadas, el atacante tenía un máximo de 1.000 intentos para entrar. Un número sensiblemente mayor al que ofrece cualquiera de estos servicios, generalmente protegidos bajo sistemas anti fuerza bruta.

¿El resultado? Los atacantes lograban como máximo una mejora del 0,02%.

Un 3% de mejora frente a un máximo de 0,02% de pérdida.

¿Dónde está el truco?

Muy sencillo: En aplicar contextualidad a las peticiones.

Facebook ofrece al usuario todas estas alternativas a la hora de intentar loguearse, pero siempre y cuando la conexión provenga de una IP y dispositivo ya conocido en su cuenta.

Y además, aplica un sistema más restrictivo cuando no está del todo seguro si la persona que intenta acceder es la legítima y se ha equivocado, o es un atacante que ha tenido suerte a la primera. Bajo esta premisa, basta con pedirle un dato como su fecha de nacimiento, que le verifique quienes son sus amigos de un listado de fotos de perfil, o un segundo factor de autenticación para cerciorarse de que en efecto es quien dice ser.

Unimos esas combinaciones de usuario/contraseña (un factor de seguridad negativo) con la contextualidad de la petición (un factor de seguridad positivo), y obtenemos que, mejorando considerablemente la experiencia del usuario, apenas perdemos en seguridad.

Es un win-win claro.

Hay, no obstante, algunos puntos flacos que conviene señalar. En efecto, para contraseñas que ya consideradas de antemano débiles, el que podamos incluir un carácter más debilita aún más la seguridad de esa cuenta. Imagínese por ejemplo una cuenta protegida por la contraseña 12345 a la que un ciberatacante prueba con 123456, u otra protegida bajo la contraseña password y que el atacante haya probado passwords.

Pero recalco, estamos hablando de casos muy específicos donde la robustez de esas contraseñas ya es de por sí baja. Y además, aún tendríamos que estar en el mismo dispositivo desde el que se hizo alguna de las conexiones anteriores (ergo, un ataque dirigido), puesto que si no, y debido a la contextualidad, el sistema nos pediría un segundo factor.

Quería hablar de esto ya que a veces confundimos peras con manzanas. Los servicios digitales nos tienen acostumbrados a anteponer usabilidad a seguridad y/o privacidad sencilla y llanamente porque ésta afecta más directamente al negocio que el resto. Pero esto no significa que, bien implementada, la usabilidad tenga que afectar al buen desempeño de estas dos otras cualidades del producto.

Y viceversa. La seguridad o la privacidad no tienen por qué estar reñidas con la usabilidad. Como ya he explicado en más de una ocasión, se trata de penalizar al malo, no al bueno.