¿Cómo implementar un "Recordarme" en una aplicación móvil?

Me gusta la sugerencia de symcbean de crear un valor asignado aleatorio al iniciar sesión que esté relacionado con la cuenta por separado del nombre de usuario y la contraseña. Sin embargo, para responder específicamente a su pregunta, también hay formas de cifrar los datos sin una clave asignada estática. Me gustaría generar una clave que utilice bits de información exclusivos del teléfono y recuperables a través de llamadas a la API del sistema operativo.

Editar : a instancias de @DW, elaboraré: El UDID, el número de serie y otra información de identificación pueden ser de calidad criptográfica y de secreto suficientes sin acceso al teléfono para evitar el descifrado de los datos almacenados. Sin embargo, el acceso a los datos almacenados implica un acceso probable al teléfono también. Por lo tanto, cualquier nivel de seguridad a través del cifrado local del dispositivo es una simple oscuridad.

Otros encuestados han sugerido almacenar un valor aleatorio como se hace en las sesiones HTTP. Parece que el solicitante original no está usando HTTP y no cree que este método se aplique a su software. Sin embargo, la implementación lógica de almacenar y transmitir un valor aleatorio es aplicable a cualquier protocolo de transporte. Lo sugiero fuertemente.

Alternativamente, las credenciales se pueden almacenar en el teléfono mediante el cifrado de clave pública. La aplicación puede cifrar el nombre de usuario y la contraseña al ingresar con la clave pública del servidor. Por lo tanto, los datos de inicio de sesión serían ilegibles incluso si el dispositivo estuviera comprometido.

Cuando el objetivo es evitar la recuperación de las credenciales de inicio de sesión, creo que lo mejor es utilizar un identificador temporal aleatorio. Esto excluye cualquier problema de mantener los datos del servidor (una clave privada) en secreto y disponibles. Si esa clave fuera revelada, la protección es marginal a inútil. Si se pierde, la aplicación debe volver a implementarse con una nueva clave. Si se perdieran los datos de inicio de sesión temporales, todos se verían obligados a iniciar sesión, pero no se produciría una interrupción apreciable en el servicio.

También, use el cifrado de la clave pública del transporte (SSL o clave PGP simple incorporada en la aplicación) tanto para el inicio de sesión inicial como para cualquier otro posible dato de autenticación, ya sea el nombre de usuario y la contraseña o un valor aleatorio.

No guarde el nombre de usuario y la contraseña en el teléfono.

En cambio, te sugiero que sigas una de las siguientes dos estrategias:

• Use una cookie persistente. Esta es la solución fácil. Si se está conectando a un sitio web, haga que el servidor autentique al usuario la primera vez que inicie sesión y luego configure una cookie persistente en el teléfono del usuario que contenga una cadena de 128 bits aleatoria (criptográficamente) asociada con la cuenta del usuario. Cada vez que el usuario inicie la aplicación, cuando se ponga en contacto con el servidor a través de HTTP / HTTPS, el cliente enviará su cookie persistente, que el servidor puede usar para autenticar al cliente. Lo ideal sería utilizar HTTPS y usar cookies seguras.

• Use la autenticación de clave pública. Esta es la solución más complicada. Podría hacer que la aplicación de teléfono genere su propio par de llaves públicas / privadas. Cuando el usuario inicia sesión por primera vez, la aplicación puede enviar la clave pública y el servidor puede asociar la clave pública con esa cuenta. Cada vez que el usuario inicie la aplicación, la aplicación podrá autenticarse en el servidor mediante la clave privada.

  • Por ejemplo, si está utilizando tecnología web, es posible que el cliente genere un certificado autofirmado, se conecte al servidor mediante HTTPS y se autentique utilizando su certificado de cliente. Tendría que probar si las vistas web en Android son compatibles con certificados de clientes.

  • Alternativamente, si se conecta al servidor usando su propio protocolo personalizado, canalícelo sobre SSL o TLS, y use la función de certificados de cliente de SSL / TLS.

¡No use el nombre de usuario / contraseña para el token!

Si es posible descifrar, existe el riesgo de que se descifre. Y aunque la mayoría de las personas saben que no deberían, usan las mismas contraseñas para múltiples servicios, por lo que incluso si su servicio no es particularmente valioso, usted tiene la responsabilidad de proteger cualquier contraseña que se le dé.

La forma de resolver el problema es la misma que la gestión de sesiones HTTP: use un identificador sustituto (que puede tener el mismo valor que la cookie de sesión, pero con una vida útil más larga) luego mantenga una tabla de búsqueda del identificador sustituto, el Usuario al que fue emitido y el tiempo de caducidad.

D.W. se implementa mejor con las siguientes correcciones & detalles adicionales:

• genere un par de llaves en la aplicación, después de que el usuario se haya autenticado correctamente utilizando el mecanismo de autenticación normal y mientras se encuentre en esa sesión autenticada.
• genere un UUID en el teléfono (no use la ID del dispositivo incorporada del OS / API ni ningún otro identificador único que cualquier otra aplicación también pueda recuperar), cifrelo * y guárdelo (* vea a continuación las mejores prácticas de cifrado para datos de la aplicación en un teléfono móvil).
• use una combinación de UUID y algunos detalles del teléfono disponibles, combinados un poco (en lugar de simplemente concatenarlos) para generar un AppDeviceId que solo su App conoce.
• envíe la clave pública + AppDeviceId al servidor a través de un canal seguro (SSL / TLS firmado por una CA realmente confiable), sin compromisos, para registrar el dispositivo y la clave pública.
• ahora para encriptación: genere mediante programación una clave de encriptación usando una combinación de un UUID (no la que usa para crear AppDeviceId) y algunos detalles del teléfono disponibles, combinados un poco (en lugar de simplemente concatenarlos). Si puede vincular la contraseña / pin de bloqueo de la pantalla del teléfono aún mejor (en iOS esto se hace bajo el capó con el llavero, IFF el usuario de hecho usa una contraseña / pin de bloqueo de pantalla).
• almacene el UUID que creó para generar la clave de cifrado en el almacenamiento al que solo se le permite acceder a su aplicación (teniendo en cuenta que un dispositivo rooteado significa que cualquier aplicación o usuario probablemente pueda acceder a él de todos modos ... y esta es la punto más débil).
• cifre y almacene el UUID que creó para AppDeviceId y cifre y almacene la clave privada cifrada. Nuevamente, use el almacenamiento al que solo su aplicación tiene "permitido" acceso (teniendo en cuenta que un dispositivo rooteado significa que cualquier aplicación o usuario probablemente pueda acceder a él de todos modos).
• para autenticar en el futuro, la aplicación debe firmar una carga útil conocida tanto para la aplicación como para el servidor, por ejemplo. AppDeviceId, utiliza la clave privada y la envía a través de un canal seguro (SSL / TLS, etc.) al servidor. El servidor debe verificar la firma usando la clave pública.
• Si el servidor alguna vez recibe un intento de autenticación, usando un AppDeviceId dado, que falla, entonces elimine / elimine / olvide la clave pública registrada y bloquee cualquier intento adicional de autenticar usando este mecanismo de par de llaves hasta que el Usuario se autentique usando alguna otra, (típicamente ) técnica más segura y probada (como el proceso de autenticación que está aumentando con este nuevo, o en persona con los documentos correctos, etc.).
• agregar límite de tiempo en el par de llaves es aún mejor (mitiga el secuestro prolongado), de esa manera el Usuario debe autenticarse usando una técnica más segura y probada de vez en cuando.

A través de lo anterior, se necesitaría la descompilación e ingeniería inversa del código + acceso a los datos almacenados en el dispositivo (acceso físico al dispositivo O Aplicación maliciosa en el dispositivo rooteado) + conocimiento del dispositivo (huellas dactilares a través de algún truco O acceso físico al dispositivo O el control de una aplicación en el dispositivo) para poder usar ese par de llaves y AppDeviceId para autenticar.