Concepto de seguridad para aplicación de Android con API REST basada en PHP

6

Estoy tratando de construir mi propia API REST basada en PHP para mi aplicación de Android y estoy un poco confundido por todas las cosas de autenticación de diferentes usuarios que se pueden encontrar en Internet. Así que quiero presentar mis consideraciones de seguridad y me gustaría recibir algunos comentarios.

Primero, quiero dejar claro que no quiero crear una API pública donde terceros puedan registrarse para obtener una clave de API, en cambio, solo quiero que los usuarios de mi aplicación puedan hacer todo el registro / inicio de sesión / enviando solicitudes de cosas. Así que mis planes son los siguientes:

  1. Cuando un usuario desea registrarse, mi aplicación primero intercambia las claves generadas con mi servidor utilizando el método Diffie-Hellman. Para esto, mi servidor y mi aplicación almacenan información sobre el mismo número primo y la misma base (a menudo llamados p y g). Mi aplicación genera un secreto y crea una clave pública a partir de p, g y el secreto. La clave pública se envía al servidor, que responde con el envío de una ID de usuario en el formato UUID de Java y la clave pública del servidor según el secreto del servidor, p, y g. Al final, ambas partes son capaces de generar un secreto común. Toda la transacción se realiza utilizando TSL / SSL y puede verse aquí . En lugar de todo el secreto numérico, bastante largo, se almacena un hash SHA-512 en la base de datos y en la aplicación.

  2. Después de intercambiar la clave, ahora puedo enviar la información de la cuenta del usuario (ID de usuario, contraseña y otras cosas) al servidor mediante TSL / SSL. El secreto de la aplicación se usa para HMAC asegurándose de que la instancia de la aplicación (el usuario) esté autorizada para enviarme estas cosas. Puedo verificar esto mientras almacené el secreto hash SHA-512 y el ID de usuario en la base de datos. La contraseña debe transmitirse para poder volver a iniciar sesión si el usuario se desconectó o si desea cambiar su contraseña. La contraseña está en hash siguiendo estas instrucciones. Después de iniciar sesión, se devuelve un token de inicio de sesión aleatorio al usuario que representa su estado de inicio de sesión. Este token de inicio de sesión también se almacena en la base de datos.

  3. En lugar de enviar las credenciales del usuario con cada solicitud, el token de inicio de sesión se utiliza como credenciales de inicio de sesión y el secreto generado en el primer paso se utiliza para hacer HMAC. Entonces, si recibo una solicitud, primero puedo verificar si el usuario está autorizado para enviarme una solicitud realizando la autenticación del mensaje con HMAC y luego puedo verificar si el usuario ha iniciado sesión comparando el token de inicio de sesión transmitido con el almacenado en el base de datos. Esta transacción también se puede realizar con TSL / SSL pero no es necesario.

¿Es este un concepto válido o carece de algunos puntos cruciales, contiene malentendidos o hay algún otro tipo de problema con él?

    
pregunta zersaegen 29.07.2014 - 13:59
fuente

2 respuestas

2

Este sistema de seguridad propuesto es vulnerable a CWE-602: cumplimiento del lado del cliente de la seguridad del lado del servidor , y no limita la capacidad de un atacante para acceder a esta API RESTful. Fundamentalmente, cualquier secreto proporcionado a la aplicación móvil será conocido por el atacante. Un atacante con un teléfono roto en la cárcel puede observar la memoria utilizada por cualquier proceso en ejecución.

Se debe suponer que un atacante tendrá acceso completo a su API. Cualquier funcionalidad proporcionada al cliente es, por definición, accesible al atacante y debe someterse a una revisión de seguridad. Un buen lugar para comenzar es buscar los problemas encontrados en Top 10 de OWASP .

    
respondido por el rook 14.09.2014 - 22:38
fuente
0

No es realmente una descripción detallada, pero por lo que entendí, tengo algunas preguntas :)

En el paso 1: el intercambio de claves Diffie-Hellman es vulnerable a un ataque de hombre en el medio. Incluso si se está ejecutando dentro de una conexión segura TLS / SSL. La única forma de evitarlo es utilizar certificados PKI.

En el paso 2: ¿Cómo planea reciclar el token seguro? Me refiero a cuánto tiempo es válido para la autenticación? Estoy seguro de que pensaste en eso. REST no tiene estado, por lo tanto, no estoy seguro de qué quiere decir con iniciar sesión / cerrar sesión. No tienes sesión para validar. Creo que el token debería ser válido para una ventana de tiempo específica.

En el Paso 3: si la conexión no es segura por TLS / SSL, ¿cómo planea evitar que alguien escuche la conexión? / p>     

respondido por el Ubaidah 15.10.2014 - 01:34
fuente

Lea otras preguntas en las etiquetas