¿OAuth no es seguro o no lo entendí?

Question

Estaba pensando en la seguridad de mi API de servicio web REST, y decidí echar un vistazo a otros servicios grandes y cómo lo hacen. Como ejemplo, decidí estudiar OAuth de Twitter. Después de leer la guía para principiantes, estoy un poco confundido y conmocionado.

que he entendido que es proveedor de servicio la responsabilidad para autenticar usuarios y para mostrar qué tipo de usuario el acceso del consumidor es exigente (por ejemplo, que quieren de acceso de sólo lectura a los recursos específicos). Pero vi proveedores de servicios que no informan al usuario sobre qué tipo de acceso exige el consumidor (e incluso ahora muestra la identidad del consumidor). La segunda parte del problema es que el consumidor puede mostrar su propio formulario personalizado de Autenticación del servicio del proveedor en IFrame, y simplemente ocultar los detalles de acceso, simplemente puede robarle la contraseña, o solicitar acceso ilimitado a sus recursos, puede hacer básicamente lo que quiera, hay muchas formas de engañar al usuario.

Como ejemplo tomemos LinkedIn. Solicitan su nombre de usuario y contraseña de Gmail dentro de su propio formulario, y no tienen idea de cómo lo usarán. Pueden simplemente robarlo y almacenarlo en su base de datos, pueden hacerlo mediante OAuth a Gmail (y no muestran la página de Gmail con información sobre el tipo de acceso que solicitan), pueden hacer lo que quieran con esta información.

Lo que estoy tratando de decir no es que el protocolo de comunicación OAuth no sea seguro, sino que hay muchas maneras de usarlo incorrectamente para engañar al usuario y obtener sus credenciales.

BTW había flujo de seguridad en el propio protocolo OAuth http://oauth.net/advisories/2009-1/) y estoy bastante seguro de que hay más, pero a nadie le importa encontrarlos.

Answer 1

Voy a ir con 'Usted no entiende.' (En su defensa, muy pocas personas).

Seamos claros: el ataque de fijación de sesión al que se refiere afecta a OAuth 1.0, pero se resolvió en OAuth 1.0a, que se convirtió en RFC 5849. No hay implementadores importantes de OAuth 1.0: los principales implementadores implementaron OAuth 1.0a/RFC 5849 o implementaron uno de los borradores de OAuth 2.0.

En cuanto a la anti-patrón de nombre de usuario/contraseña, OAuth 1.0a no prevé un mecanismo para intercambiar un nombre de usuario y la contraseña de un token de acceso. OAuth 2.0 sí, pero solo con el propósito de soportar aplicaciones instaladas. Tenga en cuenta que una aplicación instalada simplemente podría registrar con keylog (o similar) si realmente quisiera. Cuando se trata de seguridad, todas las apuestas están desactivadas si una aplicación ya se está ejecutando de forma nativa y no se encuentra en la arena en la máquina del cliente. Pero este es en realidad un escenario muy diferente de lo que estás hablando. Las aplicaciones web en OAuth 1.0a y OAuth 2.0 nunca tocan el nombre de usuario y la contraseña.

El flujo de OAuth 1.0a dice así: La aplicación solicita al proveedor para un identificador de petición, diciendo que todas las cosas que quiere acceder.El proveedor emite el token no autorizado temporal, en cuyo punto el cliente puede enviar al usuario al proveedor para autorizar ese token. El usuario inicia sesión con su nombre de usuario y contraseña en el sitio del proveedor y luego concede o niega el acceso. Luego, el proveedor redirecciona con una cadena de verificadores que permite que el sitio se actualice a un token de acceso autorizado. Todas estas interacciones están firmadas. Si las firmas no coinciden en ninguna de ellas, el proveedor rechazará la solicitud. Y el usuario puede revocar cualquier token en cualquier momento, eliminando la capacidad del cliente de acceder a su cuenta.

Hay un número de security considerations con el protocolo, pero si realmente lee la lista, es esencialmente la misma lista de problemas de seguridad que afectan a casi todos los sitios en Internet. Estas consideraciones de seguridad son muy conocidas y muy bien entendidas. Que yo sepa, actualmente no se conocen ataques explotables contra proveedores que aborden correctamente todas estas consideraciones de seguridad.

Por lo tanto, está mucho más seguro al utilizar OAuth 1.0a u OAuth 2.0 para autorizar a un tercero que con cualquiera de las alternativas. Si no se siente cómodo con esto, la solución es simple: no autorice a terceros a acceder a su cuenta. Ciertamente hay muchas razones por las cuales no querrás hacer eso.

Answer 2

Parece que no está seguro de lo que no es seguro. Según tengo entendido, el protocolo OAuth en sí mismo, si se implementa correctamente, es seguro. Es solo que es fácil de implementar incorrectamente, y los usuarios se confunden porque realmente no entienden lo que están haciendo.

Por ejemplo, lo que LinkedIn está haciendo está mal. Nunca les daría la información de mi cuenta de Gmail de esta manera. Para poder proporcionar la información de mi cuenta de gmail, insisto en que mi navegador esté usando SSL con Google, por lo que el marco raíz de la página proviene de Google.

Luego está la cuestión de confiar en Google para decirme correctamente lo que el acceso se está solicitando y por quién. Si no confío en que hagan esto, no debería usar OAuth.