¿Qué puedo hacer para aumentar la seguridad de mi aplicación basada en un secreto compartido?

Question

¿Qué puedo hacer para aumentar la seguridad de mi aplicación basada en un secreto compartido?

#1 de HTLee (1 votos)
#2 de Sebi (0 votos)

2

Estoy trabajando en una aplicación que se ejecutará en un televisor de usuarios y tiene una aplicación móvil complementaria.

Quería presentar un código QR a mis usuarios desde la aplicación de TV, que luego es escaneada por la cámara de la aplicación móvil complementaria. Originalmente, estaba pensando en codificar un UUID v4 en el código QR y usarlo como un secreto compartido entre las dos aplicaciones. Este valor identificará de forma única ese dispositivo de TV en particular.

Una vez que se hayan intercambiado los secretos compartidos, las aplicaciones se conectarán a mi servidor a través de sockets web y escucharán / emitirán eventos para ese UUID. No habría otras contraseñas o nombres de usuario. Esta comunicación de socket web se haría usando WSS / TLS.

Este servicio es un sistema de transporte de mensajes muy simple entre la aplicación móvil y la aplicación de TV. No hay una base de datos, ningún usuario, etc. Todos los mensajes son directos.

¿Qué tan mala es una idea? Si el secreto compartido es casi imposible de adivinar, a primera vista me parece bastante seguro. ¿Hay alguna forma de hacerlo más seguro?

Una de las ideas que tuve fue utilizar alguna forma de TOTP . Ese sistema también se basa en un secreto compartido, pero utiliza un componente basado en el tiempo para modificar el secreto antes de intercambiar / comparar. Esto evitaría la exposición de mi verdadero secreto y evitaría los ataques de repetición. Sin embargo, para mi aplicación, necesitaría una ventana de tiempo mucho más grande que el TOPT tradicional, ya que me gustaría que esta clave fuera válida por más de unos pocos segundos.

secret-sharing

pregunta mmcdole 25.09.2015 - 04:28

fuente

2 respuestas

Lea otras preguntas en las etiquetas secret-sharing

¿Qué son los “datos del titular de la tarjeta” en el contexto de SAQ A de PCI-DSS? Servidor de almacenamiento y reenvío SMTP compatible con TLS: ¿tiene que almacenar claves privadas?

score 1 · Answer 1

Este es un problema que ha sido resuelto por OAuth 2 y Open ID Connect (OIDC). Yo sugeriría fuertemente construir sobre él en lugar de inventar su propio protocolo. Eche un vistazo al flujo de trabajo del dispositivo OAuth 2 (Google tiene una excelente descripción) .

En primer lugar, ayuda a dividir la autenticación de la autorización. La autorización es lo que quiere lograr (es decir, autorizar el televisor). Si el flujo de trabajo de autenticación requiere inicio de sesión o no, o involucra múltiples factores es algo que se debe considerar separado del flujo de trabajo de autorización y puede ser algo que usted quiera configurar.

El diagrama a continuación describe el flujo de trabajo del dispositivo OAuth 2.

TV app                                    Server
   |                                        |
   |----------- request code -------------->|
   |<------- url & auth code (QR) ----------|
   |                                        |
   |   code             mobile     user     |
   |-- & url --> user --> app --> login? -->|
   |                                        |
   |---------------- poll ----------------->|
   |<-------------- token ------------------|
   |------- use token to register --------->|

El código de autenticación puede estar en formato QR que el usuario escanea con la aplicación móvil, o simplemente puede ser un código que el usuario tendrá que escribir manualmente en su aplicación móvil.

En el enlace de Google mencionado anteriormente, lo que describen como ID de dispositivo puede ser el UUID que mencionaste, pero también podría ser una cadena aleatoria generada de forma segura asociada a tu aplicación.

Hay directrices en OAuth 2 y OIDC para utilizar secretos compartidos, que solo son necesarias para proteger las credenciales. En el flujo de trabajo anterior, ya que la aplicación móvil es responsable de la autenticación, tiene la opción de usar un secreto compartido con el Servidor (también conocido como cliente confidencial) o no (también conocido como cliente público).

La pregunta de si necesita autenticación depende de dónde reside su servidor. Si se encuentra en Internet, se recomienda la autenticación: muchas bibliotecas / aplicaciones del servidor OAuth 2 le permiten integrarse con varias cuentas de redes sociales, por lo que puede que no sea tan doloroso como parece. Por otro lado, si el Servidor reside en la red local del usuario, entonces tal vez la autenticación no sea necesaria.

Hay muchas bibliotecas OAuth 2 / OIDC de cliente y servidor que harán su vida más fácil. Para el lado del servidor, incluso puede hacer uso de aplicaciones de servidor (por ejemplo, Keycloak ) características deportivas como TOTP para mejorar la seguridad.

score 0 · Answer 2

Como se indicó, su enfoque usaría la misma clave (ya que no usa un directorio de claves) para todas las aplicaciones. Por lo tanto, obtener la clave de un dispositivo utilizando la aplicación permitiría descifrar los mensajes cifrados enviados por todos los dispositivos que utilizan esa aplicación. Debes responder las siguientes preguntas:

¿Cómo se generan las claves?
¿Cuál es el parámetro de seguridad deseado (longitud de la clave en bits)?
¿Qué tan fácil es recuperar la clave de la aplicación?

Definir la clave en un código qr definitivamente no es una buena idea, ya que se puede recuperar fácilmente de su forma codificada. La clave debe mantenerse en secreto .

En lugar de un algoritmo de encriptación / autenticación tradicional, es mucho más recomendable utilizar un enfoque de seguridad comprobada, como TLS.