¿Cómo mantener el secreto del consumidor de OAuth seguro, y cómo reaccionar cuando está en peligro?

Question

Esta pregunta trata de intentar 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 del consumidor se ha visto comprometido, y un hacker lo ha conseguido, ¿cuáles son las consecuencias de esto?

supuestos

Secret Consumidor comprometida
Estoy en lo correcto al afirmar que un secreto del consumidor comprometido, como tal, no tiene ningún efecto sobre la seguridad del usuario, o los datos almacenados en el proveedor OAuth permitido que el usuario estaba interactuando con. Los datos en sí no están comprometidos y no pueden ser recuperados por el pirata informático.

El pirata informático necesitarí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 soy yo razón al afirmar lo siguiente:

• El hacker puede instalar/publicar una aplicación que imita mi aplicación.
• El hacker puede atraer a los usuarios que irán a través del flujo de OAuth, recuperar un token de acceso a través de la hackers OAuth danza (utilizando la clave comprometida consumidor /secreta).
• El usuario puede pensar que está tratando con mi aplicación, ya que él verá un nombre familiar (clave de consumidor) durante el proceso de autorización.
• Cuando un consumidor emite una solicitud a través de el hacker, el hacker puede fácilmente interceptar el token de acceso, y combinado con el secreto consumidor puede ahora firmar peticiones en mi nombre a a acceder a mis recursos.

impacto para el usuario final
En el supuesto de que

• un hacker tiene la configuración de un/ sitio de aplicación usando mi consumo secreta
• uno de mis usuarios fue enganado al autorizar acceso a esa aplicación/sitio

El followin g puede ocurrir:

• el usuario final puede ser darse cuenta de que algo raro está pasando, e informar al proveedor de servicios (por ejemplo: Google) acerca de la aplicación maliciosa
• el proveedor de servicios puede entonces revocar la clave del consumidor tendría que ser actualizado
  mi aplicación (que contiene el secreto de consumidor), como de lo contrario todos mis clientes no serían capaces de autorizar a mi solicitud hacerlo en preguntas:/secreta

consumidor de OAuth (mi solicitud) impacto en su nombre más (ya que mi secreto de consumidor ya no sería válido).

La delegación de 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 la danza OAuth y el envío de la señal de acceso para el usuario), uno tendría que proxy de todo interacciones de servicio también, 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?

Answer 1

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

alternativa servidor proxy:

La única manera que puede razonable mitigar los problemas que lista a continuación y hacer el trabajo de proxy-ing, sería ir el conjunto de nueve yardas - mover toda la lógica de negocio para tratar con los recursos en el servicio web de terceros a su servidor proxy, y haga 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 se encuentra en el reino de una serie de otros problemas que tienen que ver con la fiabilidad y la escalabilidad.

larga deliberación sobre qué sencillo proxy no funcionaría:

Algunas personas, cuando se enfrentan a un problema , piensan “Yo sé, voy a añadir mi propia servidor proxy” Ahora tiene dos problemas . (con disculpas a Jamie Zawinski)

Sus suposiciones son muy acertadas. 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íteme 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 es 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 sé 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 espere, hay más. 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.

---

Comenzaré por lo obvio: no hay forma de distinguir en el cableado qué software en particular 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 falsificado. 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 lo 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 aplicación incorrecta puede leer el secreto de 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.