Señales de riesgo y fricción progresiva

La fricción progresiva consiste en no tratar igual todas las sesiones: a la que se parece a las de siempre se le deja pasar sin más, a la que tiene algo raro se le pide un paso adicional y a la que acumula muchas señales se la detiene. Las señales se combinan en un puntaje y unos umbrales lo convierten en una decisión. NIST SP 800-63A-4 pide a los proveedores de identidad un programa de gestión del fraude y menciona entre sus comprobaciones la detección de cambios recientes de SIM, las huellas del dispositivo y la antigüedad del dispositivo o de la cuenta.

Un motor así tiene un punto de diseño delicado: qué hace cuando una fuente no responde. Si la ausencia de dato suma cero, el motor falla abierto: justo cuando no sabe, deja pasar como si supiera que todo está bien. En operaciones de poco daño puede ser aceptable; en las que mueven dinero o datos sensibles, no saber debe tratarse como una señal más.

Abre el laboratorio y lee motor-de-riesgo/estado-de-fuentes.txt: una fuente lleva días caída. Luego cruza los eventos de eventos-del-motor.txt que salieron con «sin dato» con el reporte que el operador mandó después por correo. Un cambio de SIM solo cuenta si ocurrió en las 72 horas anteriores al evento.

Encontrar el evento es la mitad del trabajo; la otra mitad es saber qué habría decidido el motor, porque eso es lo que se reporta al comité: no «faltó un dato», sino «con el dato, la sesión no habría entrado sin un paso adicional».

Suma los puntos de las señales que el evento tuvo más la que le faltó, con la tabla de senales-y-umbrales.txt.

OWASP describe en su catálogo de amenazas automatizadas el relleno de credenciales (OAT-008): probar en masa pares de usuario y contraseña robados en otros sitios, para ver cuáles siguen sirviendo. Su forma en un registro no es la de muchos intentos contra una cuenta, sino la de pocos intentos contra muchísimas cuentas distintas, con una pequeña fracción de aciertos que corresponden a personas que reutilizan su contraseña.

Lee intentos-por-direccion.txt mirando la relación entre intentos y cuentas distintas, y las notas.

La caída de una fuente no es un accidente raro: los operadores cambian sus servicios, vencen contratos y fallan conexiones. El diseño tiene que decidir de antemano qué pasa en ese caso y avisar a alguien cuando ocurre, en vez de enterarse por un correo días después.