¿Cómo es oAuth más seguro?

Question

Muchos servicios, por ejemplo el correo IMAP de Google, han pasado de la autenticación de ID de usuario/contraseña al uso de oAuth.

¿Cómo puede ser más seguro oAuth, además de ser un servicio proporcionado por una empresa grande y bien dotada con más recursos para monitorear?

Answer 1

Los beneficios técnicos son:

• Como la parte de "autenticación inicial" de OAuth se realiza a través de un sitio web, es más fácil solicitar otros factores de autenticación además de una contraseña. Por ejemplo, podría solicitar un código TOTP de un solo uso o una clave U2F. (También podría tener reCAPTCHA si es necesario).

  • Generalmente, esto también significa que la contraseña que estás ingresando solo es visible para el navegador web; en realidad, la aplicación de correo nunca la ve.

    Hoy en día, Google en particular es más agresivo a la hora de impedir que la página de autenticación se cargue dentro de navegadores "integrados" que podrían revelar la contraseña al programa anfitrión. (Las versiones antiguas de GNOME solían hacer esto de forma semilegítima, ya que necesitaban usar ciertas API de Google que en ese momento aún no eran compatibles con OAuth2).

  • El uso de un sitio web también permite que la interfaz de usuario sea más coherente con los servicios web reales y algo más sencilla de implementar en aplicaciones que inventar un nuevo método de autenticación personalizado de varios pasos.

    (Compárese con SSH, que tiene un método de autenticación "Teclado interactivo" que puede mostrar varios mensajes con texto personalizado; funciona bien para contraseña básica+OTP o par de claves+OTP, pero en general es bastante torpe cuando se trata de 2FA. Muchas corporaciones en realidad terminan implementar sistemas que utilizan pares de claves SSH de corta duración de una manera extremadamente similar a los tokens OAuth2 o los tickets Kerberos: usted se autentica a través del sitio web SSO corporativo para obtener una clave SSH para el día).

• El token emitido a su cliente de correo sólo tiene acceso a servicios específicos (ámbitos), en este caso IMAP y SMTP; por ejemplo, no se puede utilizar para acceder a sus archivos de Drive o a su historial de YouTube.

  • Aunque esto tiene potencial de abuso por parte del proveedor de servicios (por ejemplo, Google exige una "verificación" costosa para las aplicaciones OAuth2 que tienen más de 100 usuarios y desean acceder a ámbitos relacionados con el correo).

  • "Contraseñas de aplicaciones" generadas manualmentepodríatambién se limitará a servicios específicos, pero muy pocas personas usarían esa característica de manera efectiva; por ejemplo, esto es posible con tokens de acceso de GitHub, pero requiere demasiado esfuerzo mental para determinar (a menudo mediante prueba y error) qué alcances se necesitan para qué aplicación, por lo que Se generarán muchos tokens con todos los alcances posibles habilitados...

También existen algunas ventajas de "defensa en profundidad" para el proveedor de servicios:

• El servicio real nunca recibe su contraseña real (ni siquiera el token de actualización, solo el token de acceso de corta duración), por lo que incluso si un servicio se ve comprometido, no puede recopilar credenciales para acceder a otros servicios ("¿movimiento lateral"?).

  • Esto es muy similar al uso de tickets Kerberos en Active Directory o aserciones SAML en sistemas SSO empresariales.

    En todos estos sistemas, en lugar de que todos los servicios requieran acceso a la base de datos del usuario (y todos ellos sean objetivos valiosos), solo el KDC o el IdP se encuentran en una posición privilegiada.

Answer 2

Puedo ver al menos algunos posibles aspectos positivos.

1. Reduce la posibilidad de reutilización de la contraseña. Cuantos más lugares escriba una contraseña, mayor será la posibilidad de que se produzca una filtración crítica y, si reutiliza las contraseñas, otros sitios también estarán en riesgo.
2. Proporciona una autoridad central capaz de revocar rápidamente el acceso a una gran cantidad de sitios de una sola vez. Dado que Google sólo proporciona a los sitios un "token de acceso", todos ellos pueden ser únicos y revocarse individualmente o todos a la vez.
3. Oculta la necesidad de que los sitios manejen los cambios de contraseña y las almacenen de forma segura. Si nunca reciben una contraseña, entonces no pueden almacenarla en texto sin formato, algunos sitios lo hicieron o probablemente todavía lo hagan.
   Ellosdeberíaaún maneja el token de forma segura, pero es un proceso más simple en caso de una infracción. Informe al proveedor de OAuth sobre la infracción y ellos revocarán su token hasta que obtenga uno nuevo la próxima vez que el usuario se autentique.

Depende de que su proveedor de OAuth sea seguro, pero restablecer la contraseña en un lugar sigue siendo mucho más fácil que hacerlo en 50 o 500 sitios.