¿Cuál es el mejor modelo para llevar la autenticación de usuario fuera de línea?

Question

Estoy creando autenticación en una aplicación cliente-servidor, y algunos de los comentarios que he recibido es que debería dejar el cálculo hash al servidor (se implementó inicialmente para que el cliente recibiera el hash, calcule un hash de la contraseña ingresada del cliente, y compararlos). Parece que tiene sentido, pero me queda un problema: ¿cómo puedo autenticar a los usuarios que están fuera de línea?

Por ejemplo, si implementé un dispositivo móvil sin acceso a Internet, ¿cuál es la forma más segura de manejar la autenticación?

La forma en que lo veo, me tendrá que o bien permitir que el cliente reciba el hash + ninguna información sal, O utilizar un PIN/contraseña independiente y permitir que el cliente reciba el hash + sal de esa contraseña.

Yo preferiría esto último porque parece limitar el vector de ataque: si un dispositivo móvil se ve comprometido, la seguridad de todo el sistema (por ejemplo, todas las piezas autenticadas en la red) permanece intacta.

¿Cuáles son mis mejores opciones y consideraciones?

Answer 1

Si explica su aplicación con más detalle, podría encontrar que no estoy aquí, pero por ahora voy a hacer algunas suposiciones sobre su caso de uso y modelo de amenaza.

Según tengo entendido, tiene información delicada que desea sincronizar entre un dispositivo móvil con conectividad intermitente y algún servicio remoto. El servicio solo es accesible para usuarios autenticados, y los usuarios deben autenticarse en el dispositivo móvil para acceder a su copia de la información, incluso si está fuera de línea.

Si desea una seguridad sólida, cifre la copia del dispositivo móvil mediante cifrado basado en contraseña.

Puede utilizar la misma contraseña utilizada para autenticarse en el servicio, pero, en general, evitaría volver a utilizar la misma clave para diferentes propósitos. Un mejor enfoque sería tener una contraseña de cifrado maestra para el dispositivo móvil, que encripta la base de datos móvil, así como la "contraseña" utilizada para autenticar al usuario en el servicio de sincronización. Tenga en cuenta que la contraseña de autenticación del servicio podría ser una clave privada para la autenticación SSL client-cert o una contraseña basada en caracteres.

Deberá evaluar el riesgo de tener una sola contraseña, pero en muchos casos, creo que la conveniencia que esto ofrece al usuario, combinada con la seguridad proporcionada por una contraseña maestra sólida en lugar de dos débiles las contraseñas fáciles de recordar son un buen equilibrio.

Tenga en cuenta que este enfoque permitirá que los usuarios cuyo acceso de servicio haya sido revocado continúen accediendo a su copia local, pero sin nuevas actualizaciones. Podría incluir alguna noción de un límite de tiempo para ser aplicado por el software móvil, pero un atacante determinado podría eludir esto.

Si solo necesita la seguridad de los juguetes, su sugerencia de almacenar el hash correcto en el dispositivo móvil es adecuada, y realmente no importa si tiene la contraseña real o una alternativa, porque si usa el hash correcto, les debería llevar unos pocos miles de millones de años encontrar una colisión de contraseña que les permita acceder al servicio remoto.

Sin embargo, suponiendo que un atacante puede ver el hash de la contraseña, ¿qué impide que también miren los datos sincronizados? ¿Por qué tendrían que recuperar la contraseña? Encriptar la base de datos móvil evitaría esto.

Answer 2

Supongo que puede depender de su dominio problemático, pero para una aplicación segura, la autorización no se puede hacer por parte del cliente debido a la falta de confianza. En el caso simple que usted indicó donde el cálculo de hash y la comparación se realiza en el lado del cliente, todo lo que alguien debería hacer para obtener acceso es conectar un depurador, recorrer el código y encontrar dónde se realiza la comparación, y reemplazar un valor en la pila justo antes de la devolución (por ejemplo). Felicidades, has sido hackeado.

Me gustaría obtener más información sobre las operaciones que su aplicación específica desearía habilitar en modo "fuera de línea", y cuál sería su plan para la reconciliación una vez que el dispositivo se reconectó antes de ver la habilitación parcial funcionalidad fuera de línea.

Answer 3

Publiqué una pregunta similar hace unos minutos, y después de pensar un poco más, podría haber encontrado un enfoque aceptable, usando claves públicas/privadas. Estos son los pasos que he descrito para mi aplicación:

1. Cuando el usuario se desconecta, se puede optar por utilizar una contraseña para proteger el acceso a la aplicación sin conexión (con encriptación opcional para proteger contra el robo).

2. Al conectarse, el cliente enviará una identificación para el usuario actual (podría ser como un hash o algo que identifica de manera única a ese usuario).

3. El servidor envía un token de autorización cifrado con la clave pública de ese usuario.

4. El cliente devuelve el token descifrado con su clave privada.

5. El servidor finalmente envía un token de sesión para continuar las comunicaciones (este último paso puede ser innecesario, ¿tal vez se puede usar el token de autorización ya establecido?).

No soy un experto en el cifrado o la seguridad, pero parecería a mí este enfoque es muy seguro, ya que la única manera que se me ocurre para introducirse en el servidor sería que el atacante tenga el la clave privada del usuario junto con su frase de contraseña.

En el caso de datos confidenciales, esto puede protegerse mediante encriptación como mencioné, ya sea con una contraseña solo para autenticar al usuario o con los datos encriptados para que el dispositivo se pierda y no se vea comprometido .