Cómo garantizar que la gente se equivoque y se enoje cuando ingresa su PIN

Por Cristian Bravo Lillo, Director del CSIRT
payment

Es martes por la noche. Mañana es la charla de concienciación, pero ya llevo varias conversaciones sobre el tema en el cuerpo. El tema genera mucha inquietud entre los encargados de ciberseguridad.

Ya te fuiste para la oficina. ¿No que hoy era martes de familia?

Ah, cierto. Le prometí a mi señora y a mi hija que hoy sería martes de familia, así que nada de conversaciones sobre el valor de la ciberseguridad, ni de cómo la ciberseguridad tiene que ser cómoda para funcionar. Porque sin comodidad, no hay paciencia que aguante.

Cierto, amor, perdona. ¿Cómo anduvo el día para cada una, todo bien?

Consigo olvidarme de la oficina y nos trasladamos en la conversación a la oficina de mi señora y al colegio de mi hija. Luego de una media hora de reírnos un rato de nosotros mismos, pedimos la cuenta.

Y sucede lo de siempre. Sólo que esta vez un poco peor.

Oiga, ¿qué demonios le pasó a esta máquina?

Nada, don Cristian. ¿Por qué, está mal la cantidad?

¡Los números están en desorden!

Sí, es que es una máquina nueva. La compañía dice que es por un tema de seguridad.

scrambled-keyboard-2

Un tema de seguridad

Cuando tomamos una decisión de diseño en un sistema, tenemos que pensar en el usuario. Sobre todo cuando el resultado del diseño tiene consecuencias de ciberseguridad. Es lo que se conoce como "seguridad por diseño" (security by design), que está muy de moda pero que nadie parece conocer lo suficiente como para dar un ejemplo. Así que le saqué una foto al teclado del POS (Point-Of-Sale) para poder escribir ese ejemplo.

Para analizar un problema de seguridad, necesitamos un método. Vamos a ocupar el método más sencillo posible, donde tenemos que describir dos elementos: el caso de uso y la amenaza. Luego, para cada amenaza, encontramos alguna forma de anularla o mitigarla. Vamos por partes.

1. El caso de uso

Una persona está pagando una comida en un restaurant. El proceso es como sigue (hay pasos antes y después de éstos, pero los omito por simplicidad):

  1. El dependiente pregunta al cliente cómo pagará.
  2. El cliente dice que pagará con tarjeta de débito. El dependiente ingresa el tipo de pago en el terminal POS.
  3. El dependiente pregunta al cliente si desea incluir la propina. El cliente dice que sí.
  4. El dependiente ingresa la cantidad a pagar, incluyendo la propina, en el POS, y luego le pasa el POS al cliente.
  5. El cliente acerca su tarjeta de débito al POS, hasta que es reconocida. Si la tarjeta es reconocida, suena un beep (una forma de feedback de la conexión exitosa). Esta es una autenticación del tipo what-you-have: antes de esto el POS no conoce la identidad del medio de pago.
  6. El POS envía al banco el número de identificación de la tarjeta, y pregunta por el PIN asociado a la tarjeta. El banco envía el PIN de la tarjeta al POS.
  7. El POS despliega la cantidad a pagar, y muestra un teclado para que el cliente ingrese su PIN. Esta es una autenticación del tipo what-you-know.
  8. El cliente ingresa su PIN y presiona el botón verde. Cuando se presiona el botón verde, se compara el PIN ingresado con el PIN recuperado desde el banco. Si ambos coinciden, la transacción es aprobada; en caso contrario, la transacción es rechazada ("PIN inválido").

2. La amenaza

Usualmente existen múltiples escenarios de amenaza aplicables a un caso de uso. Encontrarlos todos es más un arte que una ciencia. Nos interesan sólo aquellos escenarios donde:

  1. La amenaza se relaciona directamente con ciberseguridad: apuntar al cliente con un arma y obligarlo a pagar un millón de dólares no es realmente una amenaza de ciberseguridad, sino una de seguridad física (y debe ser resuelta de otra manera).
  2. La amenaza es relevante: si una persona salta sobre la mesa y baila sobre el terminal POS justo cuando el cliente está ingresando su PIN (durante el paso 8), dado que se está interrumpiendo el caso de uso en un momento crítico, es definitivamente una amenaza. Sin embargo, la probabilidad de que esto suceda es muy baja, y podemos simplemente ignorar escenarios como éste.

En el caso de uso anterior, existen muchos escenarios de amenaza posibles, pero me detendré sólo en uno: que el dependiente, o cualquier otra persona, observe el número ingresado en el teclado numérico, ya sea directamente o a través de una cámara, y abuse de este conocimiento. Esto se conoce en seguridad como shoulder-surfing.

Para saber si lo anterior es realmente una amenaza, tendríamos que estudiar cuán fácil o difícil es observar con precisión el número ingresado en el teclado del POS. En la práctica no es tan fácil como uno creería: el teclado es pequeño, desde muchos ángulos la mano tapa el teclado, y no es posible distinguir qué números están siendo tecleados. Tal vez alguien piense que basta con observar los movimientos de la mano, porque los teclados en el terminal POS tienen siempre los dígitos en la misma posición relativa.

Supongamos que decidimos que la amenaza anterior es suficientemente grande como para querer anularla o mitigarla. Casi me parece escuchar a algún creativo en el Banco diciendo:

– Jefe, ¿y si ponemos los números en posiciones aleatorias cada vez que se despliegue el teclado numérico?

(¿Que cómo sé que las posiciones son aleatorias? Bueno, le saqué dos fotos a dos teclados en dos momentos distintos, y no coincidían).

Una pésima solución en busca de un problema (que no existe)

No hace falta haber hecho un master o un doctorado para intuir por qué lo anterior es una pésima solución.

Cuando una persona teclea su PIN en un teclado "normal" (es decir, donde los números están en orden), lo ha hecho cientos de veces antes; tanto, que se ha generado "memoria kinésica": la serie de movimiento es casi automática, la persona es apenas conciente de lo que hace, y puede hacerlo de forma relativamente rápida casi sin prestar atención. Para un observador casual, seguir el movimiento del dedo con la vista para memorizar el PIN es relativamente difícil (es posible que si se graba el movimiento con una cámara sea más sencillo).

Cuando se pone los dígitos en posiciones aleatorias, la memoria kinésica no sirve, el movimiento deja de ser automático, y la persona tiene que hacer un ejercicio desagradable: repetir en la memoria cada uno de los números del PIN, y encontrar cada uno para poder tipearlo. Existe una ley empírica que describe el tiempo que demorará la persona en este proceso: la ley de Fitts. Intuitivamente, el proceso será más lento que en un teclado normal. Es posible que incluso repita los números a media voz para ayudarse a tipearlos, con lo que haría incluso más fácil "espiar" el PIN.

Imaginemos además que la persona tiene dificultades cognitivas, motoras, o visuales. Por ejemplo, supongamos que tiene presbicia (que tiene una prevalencia de alrededor del 60% para los mayores de 40 años): esto le va a hacer alejar el dispositivo, haciendo más fácil incluso espiar el PIN.

No hace falta imaginar una enfermedad. Supongamos que la persona se acaba de tomar un pisco sour catedral. No sólo le estás poniendo una tarea realmente difícil por delante: es probable que le hagas pasar un mal rato.

¿Y si se equivoca tres veces (o cinco) de PIN, se bloquea la tarjeta? No quisiera hacer la prueba, pero es posible que así sea.

¿Cuál es la moraleja?

¿Tiene alguna ventaja o consecuencia positiva cambiar los números de lugar? Es posible, pero comparado con el costo de usabilidad impuesto al usuario, cualquier posible ventaja será menor.

Casi nunca vale la pena modificar el diseño de un modelo mental tan básico como un teclado numérico. Como las personas están acostumbradas al modelo, modificarlo produce molestia y frustración; las obliga a detenerse y a pensar lo que están haciendo, con lo que se demoran más y cometen más errores.

En otras palabras: nunca tomes pisco sour sin antes ver el teclado con el que vas a pagar.

Escrito por
Cristian Bravo Lillo
Director del CSIRT
Cristian es Ingeniero Civil en Computación de la Universidad de Chile, y Doctor en Ingeniería y Política Pública en Carnegie Mellon University, con una especialización en Seguridad Usable en el CMU Usable Privacy and Security Lab (CUPS). Ha sido profesor en el Master en Ciberseguridad de la Universidad de California, Berkeley; y ha dictado cursos de pregrado en la Universidad de Chile, la Universidad de Santiago, y la Universidad Tecnológica Metropolitana.