Usted tiene razón en que es un problema intratable muy similar al por qué el DRM nunca puede ser seguro. Puede hacer que sea muy difícil para un usuario falsificar el registro, pero en última instancia, la aplicación necesitará tener la clave necesaria para firmar digitalmente los mensajes de registro. Si la clave existe en el equipo cliente, se puede eliminar del equipo cliente.

La antigua máxima de "no hay seguridad de la información sin seguridad física" está en juego.

Entonces, mucho se reduce a qué nivel de integridad se requiere. ¿Qué posibilidades hay de que los usuarios intenten falsificar el registro? ¿Cuál es su ganancia potencial? Sería honesto con su jefe sobre cómo la seguridad perfecta no se puede lograr.

Detalles técnicos del registro

No está exactamente claro, así que pensé que lo aclararía. La aplicación debe contener una clave privada para la firma. Es posible que desee que este cliente sea específico para compartimentar el riesgo. Hay formas de hacer que la extracción de esta clave privada sea más difícil, pero es importante ser abierto y transparente, por lo que no se puede hacer imposible. La clave pública es conocida tanto por el usuario como por usted para autenticar el registro. La aplicación firma el mensaje de registro y luego lo cifra con una clave derivada de la contraseña del usuario.

Dependiendo del nivel de seguridad y costo del software, alguien en el equipo puede sugerir el uso de un dongle de hardware o un token USB para almacenar la clave privada. Solo tenga en cuenta que si bien la clave es más segura si el atacante puede enviar un mensaje falso al dongle para su firma, el atacante puede alterar el registro sin tener acceso directo a la clave.

Detalles técnicos de la API REST

Es posible que desee reconsiderar permitir que el cliente determine si el token es válido para evitar ataques sin conexión. Si el token se almacena encriptado en la máquina cliente, un atacante con acceso al sistema de archivos podría extraer el token encriptado y forzarlo a desconectarse hasta que descubra el token válido.

Por otra parte, si el token de autenticación solo puede ser validado por el servidor, entonces la única manera de forzar la contraseña del usuario es mediante una solicitud al servidor. Esto le permite limitar el rendimiento de dichos ataques de fuerza bruta, bloquea las cuentas y prohibir ip si es necesario. Se vuelve más difícil obtener acceso no autorizado a un token. Hay dos maneras de lograr esto. El método más simple si puede hacer que los tokens sean arbitrarios sería hacer que el token sea simplemente una derivación (PBKDF2) de la contraseña del usuario.

Si el token debe ser independiente de la contraseña del usuario o está predefinido, puede cifrarlo y almacenarlo en el cliente. De esta manera, para cualquier contraseña se devuelve un token descifrado y no se pueden distinguir tokens válidos o no válidos. Sin comunicarse con el servidor.

Si recorre esta ruta, para evitar la fuga de información, los registros deberán cifrarse, no mediante una clave derivada directamente de la contraseña del usuario, sino mediante una clave proporcionada por el servidor a solicitud (con el token de autenticación adecuado). De lo contrario, un atacante puede simplemente forzar los registros sin conexión y usarlos como un canario para identificar la contraseña correcta y, por lo tanto, el token.

Yo usaría un servicio provisto externamente (Splunk on Cloud, Papertrail - hay otros pero los he usado) para asegurar una integridad razonable. O use su propio, separado del servicio (basado en una solución comercial o, por ejemplo, ELK )

La parte de confidencialidad es más complicada. Para el caso Splunk, si tiene una lista de usuarios predefinida, puede crear vistas con un contenido por usuario y otorga derechos de lectura a los usuarios apropiados. Sin embargo, esto es difícilmente escalable.