Pasos para crear un sistema de autenticación de usuario entre el dispositivo móvil y el servidor

No necesitas la mitad de esas partes. Agregarlos solo creará un sistema más complicado, con más espacio para fallas.

Podrías hacer esto:

1. Utilice fijación de certificados en el dispositivo

   Esto asegura que el dispositivo está hablando con su servidor y hace que el trabajo sea muy difícil para cualquier tercero que intente leer el flujo de datos.

2. Usando SSL, envíe el nombre de usuario y la contraseña al servidor

   Cualquier otro dato puede ser omitido. Marcas de tiempo, frases secretas, cualquier otra cosa es superflua. Podría enviar algún ID de dispositivo, puede ser útil para la contabilidad, no para la autenticación. No necesitas la información, déjala fuera. El uso de SSL le permite enviar la contraseña tal como está, sin cifrado, hash o codificación. SSL te cifrará, de forma transparente.

3. Almacene el nombre de usuario en clear, hash y agregue la contraseña

   Hashing el nombre de usuario no le da ninguna seguridad, y aumenta la dificultad para usted. El hecho de incluir la contraseña y el hash ayudará a que sus datos sobrevivan más tiempo en caso de pérdida de la base de datos. Simplemente seleccione el algoritmo de cifrado correcto, y buenas sales. Este sitio es una muy buena referencia sobre el almacenamiento de contraseñas.

4. Usa tokens con tiempo de caducidad

   Almacene los tokens en la base de datos y envíelos al cliente. No necesita cambiar el token en cada solicitud, solo necesita ver si el token coincide y no está caducado. En cada nuevo inicio de sesión, caduque los tokens anteriores.

No confíes en el cliente. No importa cuán seguro sea el código del cliente, alguien puede romperlo. Tenga esto en cuenta cuando diseñe la seguridad de su sistema.

Los pasos 1 a 3 están obsoletos, ya que no brindan seguridad aquí, solo la oscuridad. Las credenciales nunca deben estar codificadas (CWE 748).

Paso 4: bien, asegúrate de realizar el anclaje de certificados

Paso 6: ¿Cómo recuperar la contraseña de un nombre de usuario determinado si la hash? ¿Qué algoritmo estás usando?

Paso 7: por qué usar AES, por qué no generar un token aleatorio usando un generador criptográfico seguro al azar. Si usa AES, me hace pensar que el token siempre será el mismo que lo hace vulnerable a CWE-384.

Los pasos 8 y 9 parecen buenos, así es como funcionan las sesiones.

Normalmente, su aplicación no debería ser más que una interfaz para la API de su servidor. Todas las autorizaciones y autenticaciones deben realizarse en el servidor. Esto requerirá que su usuario introduzca su contraseña cada vez que puede guardarlo en la memoria. Si desea guardar las credenciales en el dispositivo, siempre será recuperable por un atacante que tenga acceso al dispositivo (para entonces ya es demasiado tarde).

Entonces, básicamente, un inicio de sesión por primera vez no debería ser más que un usuario que se registra como lo haría con una aplicación web normal. Los usuarios crean una determinada contraseña y nombre de usuario. Esto se pasa a través de SSL al servidor.

Casi no hay diferencias entre las aplicaciones web móviles y normales cuando se trata de crear aplicaciones seguras. Tiene una aplicación de servidor y una aplicación de cliente. La diferencia es que en lugar de usar un navegador, ahora creas la interfaz gráfica, que se usa para representar la información, tú mismo. Pero se aplican los mismos principios.

Sus comentarios:

Si un atacante puede obtener acceso físico o remoto a un dispositivo, ya no es su dispositivo.

SSL sniffing no existe realmente. SSL / TLS fue creado para evitar que suceda el rastreo. Una cosa para garantizar es que su aplicación verifique si los certificados SSL son válidos. Para obtener información aún más confidencial, debe realizar la fijación de certificados.