Join FlipAndroid.COM Telegram Group: https://t.me/joinchat/F_aqThGkhwcLzmI49vKAiw


Secretos de OAuth en aplicaciones para móviles

Cuando se utiliza el protocolo OAuth, se necesita una cadena secreta obtenida del servicio al que desea delegar. Si lo estás haciendo en una aplicación web, simplemente puedes guardar el secreto en tu base de datos o en el sistema de archivos, pero ¿cuál es la mejor manera de manejarlo en una aplicación para móviles (o una aplicación de escritorio)?

Almacenar la cadena en la aplicación, obviamente, no es bueno, ya que alguien podría fácilmente encontrar y abusar de ella.

Otro enfoque sería almacenarlo en su servidor, y hacer que la aplicación lo busque en cada ejecución, nunca almacenarlo en el teléfono. Esto es casi tan malo, porque hay que incluir la URL en la aplicación.

La única solución viable que puedo conseguir es obtener primero el token de acceso como normal (preferiblemente usando una vista web dentro de la aplicación) y, a continuación, encaminar toda la comunicación a través de nuestro servidor, que añadiría el secreto a la solicitud de datos y comunicarse Con el proveedor. Entonces otra vez, soy un noob de la seguridad, así que realmente quisiera oír opiniones de algunas personas sabias sobre esto. No me parece que la mayoría de las aplicaciones van a estas longitudes para garantizar la seguridad (por ejemplo, Facebook Connect parece asumir que usted pone el secreto en una cadena de derecho en su aplicación).

Otra cosa: no creo que el secreto esté involucrado en solicitar inicialmente el token de acceso, por lo que podría hacerse sin involucrar a nuestro propio servidor. ¿Estoy en lo correcto?

12 Solutions collect form web for “Secretos de OAuth en aplicaciones para móviles”

Sí, este es un problema con el diseño de OAuth al que nos enfrentamos. Optamos por sustituir todas las llamadas a través de nuestro propio servidor. OAuth no fue eliminado por completo con respecto a las aplicaciones de escritorio. No hay una solución perfecta para el problema que he encontrado sin cambiar OAuth.

Si piensa en ello y pregunta por qué tenemos secretos, lo más importante es proporcionar y deshabilitar aplicaciones. Si nuestro secreto está comprometido, entonces el proveedor sólo puede revocar la aplicación entera. Dado que tenemos que incrustar nuestro secreto en la aplicación de escritorio, estamos jodidos sorta.

La solución es tener un secreto diferente para cada aplicación de escritorio. OAuth no facilita este concepto. Una forma es que el usuario vaya y crear un secreto por su cuenta y entrar en la clave por su cuenta en su aplicación de escritorio (algunas aplicaciones de Facebook hizo algo similar durante mucho tiempo, tener el usuario y crear facebook para configurar sus personalizadas quizes y mierda). No es una gran experiencia para el usuario.

Estoy trabajando en la propuesta de un sistema de delegación para OAuth. El concepto es que usando nuestra propia clave secreta que obtenemos de nuestro proveedor, podríamos emitir nuestro propio secreto delegado a nuestros propios clientes de escritorio (uno para cada aplicación de escritorio básicamente) y luego durante el proceso de autenticación enviamos esa clave al nivel superior Proveedor que nos llama de nuevo y vuelve a validar con nosotros. De esa manera podemos revocar los propios secretos que enviamos a cada cliente de escritorio. (Tomando prestado un montón de cómo esto funciona desde SSL). Todo este sistema sería el prefecto de valor añadido webservices, así como pasar las llamadas a un tercero webservice.

El proceso también podría realizarse sin devoluciones de verificación de delegación si el proveedor de nivel superior proporciona una API para generar y revocar nuevos secretos delegados. Facebook está haciendo algo similar al permitir que las aplicaciones de Facebook permitan a los usuarios crear sub-aplicaciones.

Hay algunas conversaciones sobre el tema en línea:

http://blog.atebits.com/2009/02/fixing-oauth/ http://groups.google.com/group/twitter-development-talk/browse_thread/thread/629b03475a3d78a1/de1071bf4b820c14#de1071bf4b820c14

La solución de Twitter y Yammer es una solución de pin de autenticación: https://dev.twitter.com/oauth/pin-based https://www.yammer.com/api_oauth_security_addendum.html

Con OAU 2.0, puede almacenar el secreto en el servidor. Utilice el servidor para adquirir un token de acceso que luego se mueva a la aplicación y puede realizar llamadas desde la aplicación directamente al recurso.

Con OAuth 1.0 (Twitter), el secreto es necesario para hacer llamadas API. Proxy de llamadas a través del servidor es la única manera de asegurar que el secreto no se vea comprometido.

Ambos requieren un cierto mecanismo que su componente del servidor sabe que es su cliente que lo llama. Esto tiende a ser hecho en la instalación y el uso de un mecanismo específico de la plataforma para obtener una identificación de la aplicación de algún tipo en la llamada a su servidor.

(Soy el editor de la especificación OAuth 2.0)

Una solución podría ser codificar en clave el secreto de OAuth en el código, pero no como una cadena simple. Ofuscarlo de alguna manera – dividirlo en segmentos, cambiar caracteres por un desplazamiento, rotarlo – hacer alguna o todas estas cosas. Un cracker puede analizar su código de bytes y encontrar cadenas, pero el código de ofuscación puede ser difícil de averiguar.

No es una solución infalible, pero una solución económica.

Dependiendo del valor del exploit, algunas galletas del genio pueden ir a mayores longitudes para encontrar su código secreto. Es necesario sopesar los factores – costo de la solución de servidor anteriormente mencionado, incentivo para que las galletas gasten más esfuerzos en encontrar su código secreto, y la complejidad de la ofuscación que puede implementar.

No almacene el secreto dentro de la aplicación.

Necesita tener un servidor al que pueda acceder la aplicación a través de https (obviamente) y guardar el secreto en él.

Cuando alguien quiere iniciar sesión a través de su aplicación móvil / de escritorio, su aplicación simplemente reenvía la solicitud al servidor que luego agregará el secreto y lo enviará al proveedor de servicios. Su servidor puede decirle a su aplicación si ha tenido éxito o no.

Entonces si usted necesita conseguir cualquier información sensible del servicio (facebook, google, gorjeo, etc), la aplicación pide su servidor y su servidor lo dará a la aplicación solamente si está conectada correctamente.

Realmente no hay ninguna opción excepto almacenarla en un servidor. Nada en el lado del cliente es seguro.

Nota

Dicho esto, esto sólo le protegerá contra el cliente malintencionado, pero no contra el cliente malicioso y no cliente contra otros clientes maliciosos (phising) …

OAuth es un protocolo mucho mejor en el navegador que en el escritorio / móvil.

Aquí hay algo en que pensar. Google ofrece dos métodos de OAuth … para aplicaciones web, donde se registra el dominio y se genera una clave única, y para aplicaciones instaladas en las que se utiliza la clave "anónimo".

Tal vez he omitido algo en la lectura, pero parece que compartir la clave única de su webapp con una aplicación instalada es probablemente más seguro que usar "anonymous" en el método de aplicaciones instaladas oficialmente.

Con OAuth 2.0 puede simplemente usar el flujo del lado del cliente para obtener un token de acceso y utilizar entonces este token de acceso para autenticar todas las solicitudes adicionales. Entonces usted no necesita un secreto en absoluto.

Una buena descripción de cómo implementar esto se puede encontrar aquí: https://aaronparecki.com/articles/2012/07/29/1/oauth2-simplified#mobile-apps

Como otros han mencionado, no debería haber ningún problema real con el almacenamiento del secreto localmente en el dispositivo.

Además, siempre puedes confiar en el modelo de seguridad basado en UNIX de Android: solo tu aplicación puede acceder a lo que escribes en el sistema de archivos. Simplemente escribe la información en el objeto SharedPreferences predeterminado de tu aplicación.

Para obtener el secreto, uno tendría que obtener acceso root al teléfono Android.

No tengo un montón de experiencia con OAuth – pero no todas las solicitudes requieren no sólo el token de acceso del usuario, sino una clave de consumidor de aplicación y secreto también? Así que, incluso si alguien roba un dispositivo móvil e intenta extraer datos de él, necesitarían una clave de aplicación y un secreto para poder hacer cualquier cosa.

Siempre pensé que la intención detrás de OAuth era que cada Tom, Dick y Harry que tuviera un mashup no tuvieran que guardar sus credenciales de Twitter en claro. Creo que resuelve ese problema bastante bien a pesar de sus limitaciones. Además, no fue realmente diseñado con el iPhone en mente.

Estoy de acuerdo con Felixyz. OAuth, aunque es mejor que Basic Auth, todavía tiene un largo camino por recorrer para ser una buena solución para aplicaciones móviles. He estado jugando con el uso de OAuth para autenticar una aplicación de teléfono móvil en una aplicación de Google App Engine. El hecho de que no se puede administrar de forma fiable el secreto del consumidor en el dispositivo móvil significa que el valor predeterminado es utilizar el acceso "anónimo".

El paso de autorización del navegador de la aplicación OAuth de Google App Engine te lleva a una página en la que contiene texto como: "El sitio <some-site> solicita acceso a tu cuenta de Google para los productos que se enumeran a continuación"

YourApp (yourapp.appspot.com) – no afiliado a Google

Etc

Toma <some-site> del nombre de dominio / host utilizado en la URL de devolución de llamada que suministra, que puede ser cualquier cosa en Android si utiliza un esquema personalizado para interceptar la devolución de llamada. Así que si utiliza el acceso "anónimo" o su secreto de consumidor está comprometido, entonces cualquiera podría escribir a un consumidor que engaña al usuario para dar acceso a su aplicación gae.

La página de autorización de Google OAuth también contiene un montón de advertencias que tienen 3 niveles de gravedad, dependiendo de si está utilizando "anónimo", secreto de consumidor o claves públicas.

Bastante cosas de miedo para el usuario promedio que no es técnicamente experto. No espero tener un alto porcentaje de finalización de inscripción con ese tipo de cosas en el camino.

Esta publicación de blog aclara cómo los secretos de los consumidores no funcionan realmente con las aplicaciones instaladas. http://hueniverse.com/2009/02/should-twitter-discontinue-their-basic-auth-api/

También estoy tratando de encontrar una solución para la autenticación OAuth móvil y almacenar secretos dentro del paquete de aplicaciones en general.

Y una idea loca acaba de golpearme: La idea más simple es almacenar el secreto dentro del binario, pero ofuscado de alguna manera, o, en otras palabras, almacenar un secreto cifrado. Por lo tanto, eso significa que usted tiene que almacenar una clave para descifrar su secreto, que parece que nos han tomado círculo completo. Sin embargo, ¿por qué no utilizar una clave que ya está en el sistema operativo, es decir, se define por el sistema operativo no por su aplicación.

Por lo tanto, para aclarar mi idea es que usted elige una cadena definida por el sistema operativo, no importa cuál. A continuación, encripte su secreto utilizando esta cadena como clave y guárdela en su aplicación. A continuación, durante el tiempo de ejecución, descifrar la variable utilizando la clave, que es sólo una constante de SO. Cualquier hacker que mira a través de su binario verá una cadena cifrada, pero ninguna clave.

¿Eso funcionará?

Aquí tengo respuesta la manera segura de almacenar su información de oAuth en la aplicación móvil

https://stackoverflow.com/a/17359809/998483

https://sites.google.com/site/greateindiaclub/mobil-apps/ios/securelystoringoauthkeysiniosapplication

Facebook no implementa OAuth estrictamente hablando (todavía), pero han implementado una forma para que no se inserte su secreto en su aplicación de iPhone: https://web.archive.org/web/20091223092924/http://wiki. Developers.facebook.com/index.php/Session_Proxy

En cuanto a OAuth, sí, más lo pienso, estamos un poco rellenos. Tal vez esto lo arreglará.

FlipAndroid es un fan de Google para Android, Todo sobre Android Phones, Android Wear, Android Dev y Aplicaciones para Android Aplicaciones.