He estado leyendo sobre ataques de homógrafos de IDN , y no puedo pensar en una mejor manera de tratarlos que
¿Realmente no hay nada más que pueda hacer?
- Indique a mis usuarios que no confíen en los correos electrónicos que piden contraseñas, etc.
Es un buen movimiento. Puede reforzar este mensaje nunca enviando ningún tipo de correo electrónico que contenga enlaces. La única dificultad es que muchos clientes de correo electrónico convertirán automáticamente cadenas que parecen direcciones web a enlaces en los que se puede hacer clic. Puede reiterar que los usuarios deben escribir la dirección en su navegador para acceder a su sitio y no deben hacer clic en el enlace.
- Compre todos los dominios similares a los míos (caros y difíciles)
¿Realmente no hay nada más que pueda hacer?
El artículo de Wikipedia contiene una sección en Defensa contra el ataque . Estos son todos basados en el navegador. Podría alentar a los usuarios a usar solo los navegadores que protegen contra los IDN. Por ejemplo, el enfoque de Chrome es:
Google Chrome muestra un IDN solo si todos sus caracteres pertenecen a uno (y solo a uno) de los idiomas preferidos del usuario.
La autenticación de dos factores puede proteger contra el riesgo de que un atacante robe con éxito un nombre de usuario y contraseña y luego los use para iniciar sesión por sí mismo. Sin embargo, si el usuario cree que se ha autenticado con éxito en su sitio, esto no hace nada para mitigar el riesgo de que el usuario divulgue más detalles en su sesión iniciada con el sitio del atacante. Además, un atacante puede hacer que su sitio de phishing solicite el segundo factor de autenticación y simplemente ingresarlos en el sitio original cuando el usuario ingresa en el sitio de phishing (siempre que el atacante realice phishing en tiempo real en lugar de consultar sus registros del servidor en un tiempo posterior).
El pedir solo ciertas letras de la contraseña también se puede eludir fácilmente. Los sitios de phishing generalmente solo dirán que las dos letras ingresadas fueron incorrectas y luego pedirán otras dos hasta que se descubra la contraseña completa. Además, esto significa que no puede guardar el hash de contraseña, y los administradores de contraseñas generalmente tienen problemas para rellenar campos dinámicos como estos.
Otra solución para mitigar el phishing en general es fomentar el uso de administradores de contraseñas basados en el navegador. Estos comprueban que la URL coincida con la almacenada en el administrador de contraseñas, por lo que no completará la contraseña si hay algún ataque de homógrafo en curso.
Mi sugerencia sería utilizar la autenticación de dos factores. Si elige no usar autenticación de dos factores, sugeriría salir del juego de autenticación y usar "iniciar sesión con *", donde * es facebook / google / yahoo, etc., esto traslada la carga de prevenir ataques de pesca a las compañías que tienen el Dinero y recursos para hacerlo bien.
Consulte enlace para ver un ejemplo de un segundo fácil y barato factor a utilizar.
Como último recurso, puede usar un esquema de dos contraseñas, también conocido como contraseña más una pregunta secreta. Donde la segunda contraseña solo recopila ciertas letras de la contraseña y las letras que recolecta cambian en cada inicio de sesión, por ejemplo:
Username: ......
Password: ......
3rd, 6th and 7th letter of secret word:
3rd .. 6th .. 7th ..
Esto aumentará las posibilidades de que el usuario note un ataque de pesca antes de que el atacante haya encontrado suficiente información para iniciar sesión como usuario.
Los administradores de contraseñas (también las contraseñas almacenadas en los navegadores), que se completan automáticamente para dominios específicos, son invulnerables a tales ataques; al menos pueden ayudar a protegerse contra el robo de contraseñas.
No les importa cómo se muestra un dominio y si se parece a , buscan la cadena real en su base de datos.
El inicio de sesión basado en certificados generalmente es invulnerable a este ataque; Si bien un usuario podría haber iniciado sesión "exitosamente" en un sitio atacante, no obtendrá cualquier credencial y tampoco podría realizar un ataque de hombre en el medio.
Principalmente este es un problema de capacitación del usuario. El consejo que prefiero es:
Save the URL for the site in your bookmarks. When logging in, open
the bookmark, then enter your login details.
Otra cosa que puedes hacer es obtener un certificado de Validación ampliada (EV). Es probable que un dominio falsificado no tenga un certificado EV, lo que proporciona una diferencia visible para que los usuarios la busquen.
Un enfoque para usuarios avanzados es usar un administrador de contraseñas integrado en el navegador que vincule las credenciales a un dominio en particular. Debido a que el administrador de contraseñas está haciendo una comparación programática de dominios, no es vulnerable a la falsificación mediante homógrafos.
Desafortunadamente, los ataques homográficos y su predecesor, los ataques url fatfinger, son una de esas cosas que dependen mucho del usuario. Podría imponer la responsabilidad hacia los registradores de nombres de dominio, los emisores de certificados o el ietf (¿qué pasa con ascii :), pero necesitará un enfoque de 2 puntos para esto?
Dependiendo de su gasto presupuestario, estos costos pueden ser muy rápidos.
La solución 2FA es excelente, ya que ahora tiene un canal de comunicaciones fuera de banda para realizar la corroboración, pero también tendría que confiar en el proveedor. Todo se reduce a la gestión de riesgos y si la pérdida de datos es un obstáculo para la demostración.
Acabo de descubrir el siguiente plugin para Chrome que codifica las URL como Phunycode en todo Es hora de protegerse contra esta nueva forma de explotación . Si alguien tiene tiempo para verificar la extensión en busca de malware, sería bueno.