OAuth y vulnerabilidades de phishing, ¿están inexorablemente unidas?

Question

He estado haciendo un poco de trabajo con OAuth recientemente, y debo decir que realmente me gusta. Me gusta el concepto, y me gusta cómo proporciona una baja barrera de entrada para que los usuarios conecten los datos externos a su sitio (o para que proporcionen las aplicaciones de datos para el consumo de forma externa). Personalmente, siempre he rechazado los sitios que me piden que les proporcione mi inicio de sesión para otro sitio web directamente. Y el enfoque de OAuth "clave de valet para la web" lo resuelve muy bien.

El mayor problema que veo yo (y muchos otros), es que el flujo de trabajo estándar de OAuth fomenta el mismo tipo de comportamientos que los ataques de phishing utilizan para su beneficio. Si enseñas a tu usuario que es un comportamiento normal ser redireccionado a un sitio para proporcionar credenciales de inicio de sesión, entonces es fácil para un sitio de phishing explotar ese comportamiento normal, pero redirecciona a su sitio de clonación donde captura su nombre de usuario y contraseña.

¿Qué ha hecho (o lo ha visto hacer) para solucionar este problema?

• ¿Le dice a los usuarios que accedan al sitio de suministro de forma manual, sin enlaces automáticos o redirección? (pero luego esto aumenta la barrera de entrada)

• ¿Intenta educar a sus usuarios, y si es así, cuándo y cómo? Cualquier explicación larga de seguridad que el usuario tenga que leer también aumenta la barrera de entrada.

¿Qué más?

Answer 1

Para extender la analogía del valet: ¿cómo sabes que puedes confiar en el valet, y que no es solo alguien que lo está probando? En realidad no lo haces: simplemente haces ese juicio (quizás inconsciente) según el contexto: conoces el hotel, te has beneficiado antes, incluso puedes reconocer a la persona a la que le estás dando tu llave.

De la misma manera, cuando inicia sesión usando OAuth (o OpenID), está redirigiendo al usuario a un sitio/URL que debería ser familiar para ellos, ya que están proporcionando sus credenciales de ese sitio que se conoce para ellos

Answer 2

Creo que OAUth y phishing están inexorablemente vinculados, al menos en la forma actual de OAuth. Se han establecido sistemas para evitar el phishing, la mayoría de los HTTPs (pausa para la risa ...), pero obviamente no funciona.

El phishing es un ataque muy exitoso contra sistemas que requieren combos de nombre de usuario/contraseña. Mientras las personas usen nombres de usuario y contraseñas para autenticación, el phishing siempre será un problema. Un mejor sistema es usar criptografía asimétrica para la autenticación. Todos los navegadores modernos han incorporado soporte para tarjetas inteligentes. No se puede phishing una tarjeta en la billetera de alguien y piratear el escritorio del usuario no filtrará la clave privada. El par de claves asimétrico no tiene que estar en una tarjeta inteligente, pero creo que construye un sistema más sólido que si se implementara puramente en el software.

Answer 3

Esto no es solo un problema de OAuth, también es un problema de OpenID. Peor por supuesto, con OpenID le está dando a un sitio web su proveedor, es fácil raspar ese sitio automáticamente si no tiene uno falso y generar uno que luego dirige también a su usuario.

Es una suerte que nada serio use OpenID para autenticarse - las publicaciones de blog, los comentarios de flickr simplemente no son un objetivo jugoso.

Ahora OpenID está yendo a un lugar de mitigación cuando comienzan a desarrollar su soporte de tarjeta de información, donde una interfaz de usuario fija en forma de software del lado del cliente proporcionará una "billetera" de identidad que es segura, pero parece que MS bola ellos mismos en tarjetas de información, a pesar de que es su especificación (abierta).

No va a desaparecer pronto.

Answer 4

¿Qué hay para certificar al proveedor de oAuth al igual que la certificación SSL? Solo el proveedor certificado de oAuth es confiable. Pero el problema es que, al igual que con la certificación SSL, la CA es importante.

Answer 5

Tiene una cuenta en el sitio al que lo redireccionan, ¿no deberían implementar medidas antiphishing como una frase e imagen de firma? Esto también aprovecha cualquier capacitación existente que los usuarios hayan recibido de, por ejemplo, bancos que comúnmente usan estas medidas.

En general, la página de inicio de sesión debe presentar secretos compartidos fáciles de usar al usuario para confirmar la identidad del sitio en el que está iniciando sesión.

Como señala Jingle, un certificado SSL podría usarse para la autenticación, pero en este caso el usuario no podría cargar un certificado directamente desde el sitio en su navegador web como parte del proceso de instalación de OAuth. Si ya se ha establecido una relación de confianza con el sitio, no estoy seguro de que recurrir a una CA sea necesario.

Answer 6

Existen algunas técnicas que se pueden usar para evitar o disminuir los ataques de phishing. Hice una lista de opciones baratas:

1. Recursos de identificación mutua. Ex. ícono asociado con un usuario específico que se muestra solo después de que el usuario ingresa su nombre de usuario.
2. El uso de nombres de usuario no es determinista y evita los correos electrónicos como nombres de usuario.
3. Incluir la opción para que el usuario vea su historial de inicio de sesión.
4. QRCode que permite la autenticación en dispositivos previamente registrados como teléfonos inteligentes. Como la web de whatsapp.
5. Mostrar los números de autenticación en las páginas de inicio de sesión que el usuario puede validar en el sitio web oficial de la empresa.

Todas las opciones enumeradas anteriormente dependen en gran medida de la educación del usuario sobre la seguridad y privacidad de la información. Los asistentes que aparecen solo en la primera autenticación pueden ayudar a lograr este objetivo.