¿Se puede lograr esto con Keystore?
No creo que se ajuste a su caso de uso. Keystore está diseñado para almacenar claves criptográficas que se utilizarán para el cifrado, descifrado y firma. La idea es que estas claves estarán fuera del alcance de la aplicación al usarlas, por lo que básicamente, si necesita algo firmado o encriptado, debe llamar a una función del sistema que tenga acceso a la clave, pero no puede obtener las claves por sí mismas. Esto los protege de aplicaciones comprometidas. Esto no funciona para usted, ya que necesita acceso al token de acceso.
Si usó Keystore para cifrar y descifrar el token de acceso, esto protegería el token de acceso de otros procesos (o de ser extraído por un software forense del sistema de archivos, pero consulte la caducidad del token de acceso más abajo ...). Así que eso definitivamente mejoraría la seguridad. Pero si su aplicación estaba comprometida, un atacante aún tendría acceso al token de acceso desencriptado.
¿Hay una forma más segura de usar localstorage?
Diría que si desea protegerse contra alguien con acceso de root y / o una aplicación comprometida, entonces no. No puede proteger un secreto de la raíz, sin importar dónde lo almacene en el dispositivo, excepto tal vez en el hardware de una plataforma informática confiable (esto no es exactamente cierto: los sistemas Linux soportan las capacidades de seguridad que la raíz tiene de forma predeterminada, pero pueden ser denegadas). por el kernel, si está configurado, pero creo que eso no es muy relevante para esta discusión)
El problema con la protección de la raíz es que la raíz tiene acceso a todo lo que su aplicación puede acceder, por lo que incluso si encripta su token de acceso, la raíz tendrá acceso a la clave de encriptación y podría descifrarla. Lo mismo se aplica cuando su aplicación está comprometida.
Una forma de agregar un poco de seguridad podría ser tener un servicio alojado fuera del dispositivo, hacer una capa adicional de cifrado y descifrado del token de acceso basado en una clave revocable, por lo que si se pierde el dispositivo, podría revocar la clave asociada y luego el token de acceso cifrado en el dispositivo sería inútil. Pero para esta solución, necesitaría tener dos capas de cifrado, una en el dispositivo (de lo contrario, abriría una nueva vulnerabilidad al enviar tokens de acceso de texto sin formato a través de la red a otro servicio) y otra en el servicio. / p>
Sin embargo, esto me parece una cantidad absurda de trabajo para proteger un token de acceso (podría tener un poco más de sentido para un token de renovación de larga duración). Los tokens de acceso son generalmente de corta duración y si elimina un token de acceso tan pronto como ya no lo necesita, también aumentaría la seguridad.
Sin embargo, almacenar el token de acceso en otro lugar que no sea localstorage puede ser más seguro que localstorage, ya que se puede acceder al almacenamiento local mediante javascript, por lo que si su vista de web estaba infectada con javascript malicioso, podría robar el token de acceso. Pero debido a que su propio código en la vista web probablemente necesite acceso a él, no tendrá suerte.
BTW: Supongo que estás hablando de un token de acceso outh. el juramento se diseñó originalmente para resolver la autorización de las aplicaciones del lado del servidor que utilizan los agentes de usuario (navegadores). outh 2 luego extendió esto para incluir flujos de autorización y autenticación para otros escenarios, como aplicaciones javascript que se ejecutan en el navegador o aplicaciones ubicadas en dispositivos controlados por los propios usuarios, pero hay algunas personas (el editor original de la especificación oauth 2 entre ellos) que se quejan de que el soporte auth 2 para estos escenarios alternativos no es muy bueno / seguro.