ofuscar - proguard android studio tutorial
¿Debería ofuscar el secreto de consumidor de OAuth almacenado por la aplicación de Android? (3)
Mi aplicación para Android contiene el secreto de consumo de OAuth para la API de Twitter. Por el momento está en el archivo .properties en texto plano, por lo que no requiere esfuerzo para que alguien lo busque en APK.
¿Debo tomar medidas para ocultarlo (como, rot13 o almacenado en código Java ofuscado)? ¿O debería evitar hacer eso, ya que crearía un falso sentido de seguridad?
¿Cómo distribuye / almacena la gente el secreto de OAuth en las aplicaciones de Android? ¿Qué tan común es que el secreto sea robado y abusado?
Definitivamente leería este análisis de uno de los autores de OAuth, Eran Hammer-Lahav, que cita otro artículo que disecciona los problemas secretos de Twitter de OAuth .
Mi consejo sería ofuscar la clave para que no se pueda extraer trivialmente y deberías estar a salvo de los oportunistas y los spammers.
La opinión de Hammer-Lahav es que los secretos de OAuth no deberían revocarse y simplemente deberían usarse para recopilar estadísticas. Con suerte, Twitter sigue este consejo.
El punto principal de 0Auth es que no almacena ninguna información sensible valiosa en el dispositivo, por lo que está bien almacenar el secreto en el dispositivo (mucho mejor que las credenciales de usuario reales). En caso de que se roben los secretos de su dispositivo, el usuario siempre puede invalidar el acceso sin necesidad de cambiar sus credenciales
La verdadera pregunta es: ¿qué obtiene un atacante al robarlo ...
Debes hacer todo lo posible para proteger los secretos, pero al final, un hacker altamente motivado siempre puede acceder a él en una aplicación instalada. Entonces, es el valor del secreto vs. dificultad de extracción.
El valor del secreto del cliente es hacerse pasar por la aplicación. No da ningún acceso a los datos del usuario. Sin embargo, dado que Twitter admite la emisión automática de credenciales a aplicaciones previamente aprobadas (su inicio de sesión con flujo de Twitter), un atacante puede potencialmente crear una aplicación web con su secreto y robar datos de usuario mediante un redireccionamiento a ciegas.
El problema con la implementación de Twitter es que no le preguntan al desarrollador sobre la naturaleza de la aplicación. Si lo hicieran, para empezar no te habrían dado un secreto y bloquearían a cualquiera que construya una aplicación web usando las credenciales de tu cliente y robando datos de los usuarios que ya lo aprobaron.
La ofuscación es una opción, pero débil. Mover el secreto a un servidor web que actúa como un proxy API es otro, pero eso solo mueve el problema a otro lado porque ahora tu aplicación tiene que autenticarse contra el servidor proxy. Sin embargo, este patrón puede ser razonablemente seguro si requiere que los usuarios inicien sesión en su sitio (que puede usar, a través de vistas web, Twitter para iniciar sesión). De esta forma, alguien que intente abusar de su proxy necesitará que sus usuarios abran cuentas en su servicio, lo cual no es muy atractivo.
En resumen, adelante y ofuscarlo. No duele Considera usar el patrón proxy también. Y tal vez deje que Twitter sepa que sus políticas de seguridad "no son geniales".