Dispositivos de confianza y lo que el servidor debe dejar escrito

Marcar un dispositivo como confiable es una decisión del servidor: «este aparato pasó una verificación y lo reconozco». El reconocimiento suele apoyarse en un identificador que la app guarda y presenta, o en una clave asociada al dispositivo. Eso es un dato sobre el aparato, no sobre la persona: no prueba quién lo sostiene hoy, ni que el aparato esté libre de manipulación, y un identificador copiado puede presentarse desde otro sitio si no está atado a una clave que no salga del dispositivo.

Por eso la confianza de un dispositivo caduca, se revisa y avisa a la persona titular cuando cambia.

La política de Nogalera fija que un dispositivo pierde la confianza tras 30 días sin uso. Un dispositivo que sigue «confiable» pasado ese plazo es una puerta olvidada: si el teléfono se perdió, se vendió o se clonó, el servidor sigue recibiéndolo sin pedir un segundo factor. La revisión se hace con la fecha del informe y la columna de último uso, no con la de alta.

Abre dispositivos-de-la-cuenta.txt; la fecha de revisión está en su primera línea.

Cada dispositivo que renueva una sesión tiene que haber nacido en un evento de alta, con su segundo factor. Si el registro de autenticación muestra una renovación de un dispositivo que no figura en la lista de la cuenta ni tiene alta, hay un token usado desde un aparato que el servidor nunca verificó. No se concluye de ahí quién fue: se anota el dispositivo, el origen y la hora, y se pide revisar esa cuenta.

Cruza registro-de-autenticacion.txt con dispositivos-de-la-cuenta.txt.

El aviso de alta es el control que permite a la persona titular enterarse de que alguien añadió un aparato a su cuenta. Es barato y es lo que convierte un secuestro silencioso en uno que se nota. El registro anota, para cada alta, si el aviso se envió. Un alta sin aviso incumple la política aunque el segundo factor haya salido bien.

Mira la última columna del registro; la respuesta es el dispositivo, no la fecha.

Un registro de autenticación sirve para investigar: quién, desde qué dispositivo, desde dónde, cuándo, con qué método y con qué resultado. Esos campos permiten ordenar una cronología y detectar patrones como los de las tareas anteriores. Lo que no debe guardarse es el valor de un token ni de una clave: quien lea el registro podría usarlo. Si hace falta correlacionar, se anota un identificador del token, que no sirve para presentarse.

Esa es la diferencia entre un registro útil y uno que añade un riesgo nuevo.