android - studio - ¿Cómo mantener el secreto del consumidor de OAuth seguro, y cómo reaccionar cuando está comprometido?

retrofit oauth2 (1)

Esta pregunta trata de tratar de comprender los riesgos de seguridad involucrados en la implementación de oauth en una plataforma móvil como Android. La suposición aquí es que tenemos una aplicación de Android que tiene la clave / secreto del consumidor incrustado en el código.

Suponiendo que un secreto de consumidor se ha visto comprometido, y un hacker lo ha conseguido, ¿cuáles son las consecuencias de esto?

Supuestos secretos del consumidor comprometido
¿Tengo razón al afirmar que un secreto de consumidor comprometido como tal no tiene ningún efecto en la seguridad del usuario ni en los datos almacenados en el proveedor habilitado con OAuth con el que el usuario estaba interactuando? Los datos en sí no están comprometidos y no pueden ser recuperados por el pirata informático.

El hacker debería obtener un token de acceso de usuario válido, y eso es mucho más difícil de conseguir.

¿Qué podría hacer un hacker con un secreto de consumidor comprometido?
¿También estoy en lo correcto al afirmar lo siguiente?

El hacker puede configurar / publicar una aplicación que imita mi aplicación.
El hacker puede atraer a los usuarios que pasarán por el flujo de OAuth, recuperando un token de acceso a través de los piratas informáticos OAuth dance (utilizando la clave / secreto de consumidor comprometido).
El usuario puede pensar que está tratando con mi aplicación, ya que verá un nombre familiar (clave de consumidor) durante el proceso de autorización.
Cuando un consumidor emite una solicitud a través del hacker, el hacker puede interceptar fácilmente el token de acceso y, combinado con el secreto del consumidor, ahora puede firmar solicitudes en mi nombre para obtener acceso a mis recursos.

Impacto del usuario final
En el supuesto de que

un hacker ha configurado una aplicación / sitio usando mi secreto de consumidor
uno de mis usuarios fue engañado para autorizar el acceso a esa aplicación / sitio

Puede suceder lo siguiente:

el usuario final puede darse cuenta de que algo sospechoso está sucediendo e informar al proveedor del servicio (por ejemplo, Google) sobre la aplicación maliciosa
el proveedor del servicio puede revocar la clave / secreto del consumidor

Impacto del consumidor de OAuth (mi aplicación):
Mi aplicación (que contiene el secreto del consumidor) debería actualizarse, ya que, de lo contrario, todos mis clientes no podrían autorizar a mi aplicación a realizar solicitudes en su nombre (ya que mi secreto de consumidor ya no sería válido).

Delegando todo el tráfico de OAuth
Aunque sería posible delegar muchas de las interacciones de OAuth a través de un servidor web intermedio (haciendo el baile de OAuth y enviando el token de acceso al usuario), también tendría que representar por proxy todas las interacciones del servicio, ya que se requiere la clave / secreto del consumidor. para firmar cada solicitud ¿Es esta la única forma de mantener la clave / secreto del consumidor fuera de la aplicación móvil y almacenada en un lugar más seguro en el servidor web intermedio?

Alternativas
¿Hay alternativas para esta delegación? ¿Es posible almacenar el secreto del consumidor en el servidor web intermedio y tener algún tipo de mecanismo para que la aplicación de Android (publicada en el mercado y debidamente firmada) pueda realizar una solicitud segura al servidor web intermedio para buscar el secreto del consumidor y almacenarlo? internamente en la aplicación? ¿Se puede implementar un mecanismo para que el servidor web intermedio "sepa" que se trata de una aplicación oficial de Android que solicita el secreto del consumidor, y que el servidor web intermedio solo distribuirá el secreto del consumidor a esa aplicación particular de Android?

Resumen : Me arriesgaría y guardaría el secreto en la aplicación del cliente.

Alternativa del servidor proxy :

La única forma en que puede mitigar razonablemente los problemas que enumero a continuación y hacer que el proxy funcione, sería recorrer los nueve metros completos: mover toda la lógica comercial para tratar los recursos en el servicio web de terceros a su servidor proxy, y hacer que la aplicación del cliente sea una terminal estúpida con una interfaz de usuario rica. De esta forma, las únicas acciones que la aplicación maliciosa podría hacer para que el proxy actúe en su nombre serían solo las que legítimamente necesita su lógica de negocios.

Pero ahora te encuentras en el ámbito de una gran cantidad de otros problemas que tienen que lidiar con la fiabilidad y la escalabilidad.

Larga deliberación sobre por qué un simple proxy no funcionaría :

Algunas personas, cuando se enfrentan con un problema, piensan "Lo sé, agregaré mi propio servidor proxy" Ahora tienen dos problemas. (con disculpas a Jamie Zawinski)

Tus suposiciones son en gran medida correctas. Hasta el punto en que comienzas a pensar en tu propio servidor, ya sea que guarde el secreto y proxies las llamadas para la aplicación del cliente, o intenta determinar si la aplicación es legítima y darle el secreto. En ambos enfoques, todavía tiene que resolver el problema de "¿esta solicitud proviene de un código que escribí"?

Permítanme repetir: no hay forma de distinguir en el cable que se está ejecutando una determinada pieza de software. Si los datos en los mensajes se ven bien, nada puede probar que se trata de otra aplicación que está enviando ese mensaje .

Al final del día, si estoy escribiendo una aplicación maliciosa, no me importa si realmente conozco el verdadero secreto, siempre y cuando pueda hacer que alguien que lo sepa haga un trabajo en mi nombre. Entonces, si crees que una aplicación maliciosa puede suplantar tu aplicación a los servidores OAuth de terceros, ¿por qué estás seguro de que no puede suplantar tu aplicación a tu proxy?

Pero espera hay mas. El dominio en el que se encuentra su servicio proxy, es su identidad tanto para sus clientes como para el proveedor de OAuth (tal como lo muestra el usuario final al proveedor de OAuth). Si una aplicación maliciosa puede hacer que su servidor haga cosas malas, no solo se revoca su clave, sino que su identidad web pública ya no es confiable.

Empezaré por lo obvio: no hay forma de distinguir en el cableado qué parte del software se está ejecutando. Si los datos en los mensajes se ven bien, nada puede probar que se trata de otra aplicación que está enviando ese mensaje.

Por lo tanto, cualquier algoritmo que se base en el secreto almacenado en la aplicación puede ser falso. La fortaleza de OAuth es que nunca proporciona las credenciales del usuario a la aplicación, sino que le da a la aplicación las credenciales temporales propias que el usuario puede revocar si es necesario.

Por supuesto, el punto débil aquí es que una aplicación suficientemente buena puede hacer que el usuario confíe en ella y no revoque las credenciales, antes de que termine sus acciones nefastas.

Sin embargo, una forma de mitigar esto es el enfoque de Google de usar OAuth de 3 patas, en lugar del estándar de 2 patas. En el OAuth de 3 patas, no hay un secreto preasignado, pero en cada autenticación se emite un nuevo secreto de token de acceso, junto con cada token de acceso. Si bien esto tiene el mismo inconveniente, ya que una mala aplicación puede leer el secreto del token de la aplicación buena de su proceso, da como resultado que el usuario tenga que aprobar el acceso a la aplicación cada vez que necesita un nuevo token de acceso.

Y, por supuesto, esto también significa que es un poco más incómodo y molesto para el usuario.