Errores en el uso de OAuth para aplicaciones móviles

Bueno, la primera consideración es que SSL / TLS es absolutamente necesario para implementar correctamente.

También se deben considerar los mecanismos automáticos de 2 patas o de 3 patas. Si bien la mayoría recomendará el enfoque de tres patas más complejo (y seguro) , es posible que 2 patas tendría ventajas cuando se hace correctamente para ciertas aplicaciones.

Ha habido algunos sincronización de los descubrimientos de ataques en OAuth realizado por rootlabs . También hay riesgos en XSS / CSRF y ClickJacking (y otros ataques contra el authn), como en cualquier aplicación web.

ArsTechnica publicó dos artículos en arquitectura de seguridad OAuth , una vinculada desde Bruce Schneier .

No tengo suficientes puntos para hacer un comentario, así que agregué esto como respuesta. OAuth es, en primer lugar, un protocolo de autorización y no principalmente una autenticación. Aunque la autenticación está incorporada dentro del protocolo, no es el propósito principal.

El mayor problema con OAuth 1.0a en aplicaciones móviles y de escritorio es que la clave Consumer / Application y el secreto Consumer / Application, que se utilizan para firmar las solicitudes, se pueden extraer y exponer públicamente.

Por ejemplo, si usted es proveedor de datos y crea y entrega una clave de consumidor a una aplicación web de terceros que desea acceder a los datos de sus usuarios, la clave y el secreto siempre estarán ocultos en la web de terceros. servidor. Se supone que nadie tiene acceso a ellos (excepto algunos administradores de sistemas o desarrolladores). Pero esta clave no está expuesta públicamente al mundo.

Sin embargo, en el caso de aplicaciones móviles o de escritorio, los usuarios finales tienen que descargar estas aplicaciones en su teléfono / computadora. Por lo tanto, cualquier hacker puede descargar la aplicación y extraer el par clave / secreto del programa. En consecuencia, puede crear una aplicación maliciosa que pretende ser la aplicación del consumidor original.

Este es, con mucho, el problema más grave de OAuth que conozco, al menos en la versión 1.0a del protocolo. El problema no es tan grave, ya que los usuarios finales todavía tendrán que aprobar el acceso a la aplicación malintencionada y depende de ellos ver que tenga un nombre diferente y que pueda sospechar sobre el ACCESO que desea. Sin embargo, cuando usted, como proveedor, espera tener consumidores móviles, nunca debe confiar en que ellos sean los que dicen que son.

En cuanto a los ejemplos anteriores de ATDRE, no creo que deba preocuparse tanto, porque estos artículos presentan algunos escenarios hipotéticos y no dicen nada concreto sobre las fallas de OAuth. OAuth 1.0a es perfectamente seguro como protocolo si se realiza sobre SSL. Los ataques de los que hablan son solo ejemplos comunes de piratería web, que no tienen nada que ver con OAuth.

Por ejemplo, si alguien roba la cookie del usuario final, por supuesto que puede iniciar sesión y aprobar solicitudes en nombre del usuario ... pero esto no es un problema de OAuth. O el ejemplo de tiempo, que es un ejemplo de una implementación de biblioteca particular del protocolo, no con el protocolo en sí ...

Lamento no poder decirle detalles sobre OAuth 2.0, porque todavía no he implementado esa versión, sin embargo puedo decirle que la versión 1.0a del protocolo es buena desde el punto de vista de seguridad ...