Header Ads Widget

Ticker

6/recent/ticker-posts

¿OAuth es suficiente para la seguridad de API de grado financiero?

 


"Si piensa en dónde comenzó OAuth, realmente se trataba de proteger los comentarios en las publicaciones de blog y ahora estamos hablando de empresas, por lo que es una clase de seguridad completamente diferente".

Así es como Travis Spencer, CEO de la compañía de identidad Curity, abrió su charla en nuestra Cumbre API de Austin 2019, y es un resumen astuto de la forma en que muchos productos (particularmente en la escena tecnológica) se modifican o rediseñan más allá de su propósito original. .

Como aclaró Spencer en su charla, "cuando decimos grado bancario no solo estamos hablando de bancos, estamos hablando de atención médica, gobierno y alta seguridad". En otras palabras, la seguridad de grado financiero es algo relevante para cualquier API centrada en datos.

A menudo es cierto que los productos tienen dificultades para adaptarse a tareas para las que no fueron diseñados originalmente. En esta publicación, veremos si ese es el caso aquí o no, es decir, cómo han evolucionado los gustos de OAuth desde sus humildes comienzos y si es realmente capaz de usarse para protección de grado financiero.

Vea a Travis Spencer , CEO de Curity y fundador de las API nórdicas, presente en la Cumbre de API de Austin 2019 :

¿Puede OAuth alcanzar el éxito?

Al principio de su charla, Spencer ofrece un resumen de algunas cosas que puede hacer con su implementación de OAuth para proporcionar seguridad de grado financiero :

  • Tokens limitados mutuos de TLS
  • PKCE (clave de prueba para intercambio de código)
  • Consentimiento
  • Objetos de solicitud / respuesta firmados
  • Identificadores seudónimos por pares (PPID)
  • Tokens fantasmas
  • Autenticación fuerte
  • Ámbitos de prefijo
  • Clientes dinámicos

No se puede negar que es una lista bastante completa y sugiere que OAuth es más que capaz de defenderse cuando se trata de seguridad. En otras palabras, OAuth no debe considerarse insuficiente cuando se trata de proteger los datos. De hecho, Spencer describe varias formas en las que funciona muy bien para la protección de grado financiero.

Por ejemplo, Spencer menciona cómo los PPID se pueden usar para evitar la colusión entre aplicaciones no relacionadas y, al mismo tiempo, permitir la interacción entre, por ejemplo, sitios y sus aplicaciones móviles asociadas. También describe cómo los tokens fantasmas (frente a, digamos, un token web JSON) permiten un espacio regulado más pequeño al tiempo que evita que los clientes accedan a cualquier información de identificación personal (PII) y que los clientes de front-end dependan del contenido de los tokens de acceso.

Lea también: Explorando OAuth.tools, el primer patio de juegos OAuth del mundo

Algunas fichas son insoportables

Sin embargo, la forma en que los desarrolladores utilizan OAuth no siempre es perfecta. ¿Las dos principales vulnerabilidades de OAuth como las ve Spencer? Tokens de portador y redireccionamiento . "Esas dos cosas son los principales vectores de ataque en OAuth".

Spencer compara el primero con bonos al portador; "Si usted paga la fianza, entonces ... ¡puede obtener un millón de dólares por cada hoja de papel y tener una gran vida!" Eso es particularmente problemático aquí porque, a diferencia de los bonos al portador, no hay forma de guardar los tokens en una caja fuerte física.

"Ese es el talón de Aquiles porque, si puedo arrebatarle la ficha a otra persona, puedo convertirme en ella". Entonces, ¿cuál es una solución que puede evitar esto? "Lo opuesto a esto es un poseedor de un token de clave o un token de prueba de posesión, y eso es lo que son los tokens de restricción TLS mutuos".

De "API de grado financiero que utilizan OAuth y OpenID Connect", de Travis Spencer, director ejecutivo de Curity.

En términos simples, la adición de un hash de un certificado al proceso de intercambio de tokens significa que funciona como usar un cifrado para decodificar un mensaje; sin las credenciales adecuadas, el token no funcionará correctamente cuando se use para una llamada a la API.

Desafortunadamente, ese no es el final de la historia ...

Relacionado: Cree API compatibles con GDPR con OAuth y OpenID Connect

Fuera de los PKCE

Cuando habla de redireccionamientos, Spencer se refiere a la vulnerabilidad en las devoluciones de llamada que existe si ...

  • No es confidencial, es decir, no se realiza a través de TLS
  • No se realiza ninguna autenticación en el punto final del token
  • La devolución de llamada no es única por cliente ni por operador de cliente

"En los casos en los que es posible que un mal actor intercepte las credenciales, es posible que pueda eludir por completo el uso de tokens TLS mutuos descritos anteriormente". También destaca que esto es algo particularmente frecuente en los dispositivos móviles.

¿La solución? Proof Keys for Code Exchange (PKCE). "Podemos agregar un paso 0 en este proceso ... La aplicación legítima utiliza una clave de prueba para demostrar que es la aplicación real la que inició este flujo, y el servidor OAuth se niega a finalizarlo a menos que se verifique esa prueba".

Podrías pensar en esto como una versión más robusta de "ah ah ah, no dijiste la palabra mágica" de Dennis Nedry en Jurassic Park ...

Lea también: Gestión de usuarios estandarizada con SCIM

Firmado sellado entregado

Spencer destaca el problema de que, en la mayoría de los casos, los flujos de OAuth pasan por el agente de usuario. El malware instalado en el navegador, por ejemplo, en el lado del usuario, puede socavar todas las medidas tomadas anteriormente.

"¿Cómo sabemos que los flujos de OAuth no se manipulan durante el vuelo?" Pregunta Spencer. "Firmamos la solicitud del cliente enviada al servidor y viceversa ... También podemos firmar la respuesta que se envía al cliente para que sepan que no se manipuló nada en el camino de regreso".

Toda esta firma y hash es algo que ya ha demostrado su valía en los últimos años: lea un artículo sobre fugas de datos de grandes empresas y notará, en los casos en que se ha hecho, lo ansiosos que están por hablar sobre el hash de contraseñas.

Aunque el hash de contraseñas, la firma de solicitudes, etc.no siempre es 100% seguro, hay casos, por ejemplo, en los que se ha descifrado el hash débil. En este momento, es lo mejor que podemos hacer.

¿Qué sigue para la seguridad API de grado financiero?

Parece probable, al menos por ahora, que el status quo continúe como la norma en el mundo de las API de grado financiero y financiero.

Desde PayPal y Stripe hasta Coinbase, y probablemente Libra de Facebook en un futuro no muy lejano, hay muchos servicios financieros que utilizan API que se basan en marcos y servicios existentes como OAuth .

Si los servicios financieros reales ya se basan en estos, entonces hay muy pocos incentivos para que otros desarrolladores de API vayan más allá de lo que ya constituye, en efecto, seguridad de API de grado financiero ... salvo fugas masivas de datos o la exposición de vulnerabilidades graves.

Mientras tanto, esperaríamos ver que OAuth continúe siendo una de esas raras excepciones: un servicio que se creó con algo menor (asegurar los comentarios del blog) se ha expandido efectivamente a algo mucho más sólido que su intención original.

Publicar un comentario

0 Comentarios