¿Deberíamos bloquear toda la autenticación de texto simple y requerir la autenticación a través de un canal cifrado?

2

¿Deberíamos configurar nuestros servidores para requerir que la autenticación se realice en un canal cifrado y bloquear todos los métodos de autenticación de texto sin cifrado sin cifrar?

Recientemente configuré mis servidores para deshabilitar todas las formas de autenticación de texto simple y requerir que los usuarios se autentiquen a través de un canal cifrado con SSL. Por ejemplo:

  • Deshabilité la autenticación de texto simple POP3: ahora los usuarios solo pueden autenticarse a través de SSL (IMAPS)
  • Deshabilité la autenticación de texto simple SMTP: ahora los usuarios deben autenticarse a través de SMTPS (ESMPTSA)
  • Deshabilité RPC de Exchange: ahora los usuarios deben autenticarse a través de SSL (HTTPS)
  • Deshabilité la autenticación HTTP de texto sin formato: ahora los usuarios deben autenticarse a través de SSL (HTTPS), incluido el backend de mi sitio web, el correo web y otras aplicaciones web. Los usuarios que intentan conectarse a través de HTTP reciben un redireccionamiento 301 a HTTPS.
  • Deshabilité la autenticación de texto sin formato de FTP: ahora los usuarios deben autenticarse a través de SSL (solo FTPS)
  • Deshabilité el acceso a la API desde sitios web externos (pasarelas de pago, etc.)

Lo implementé a través de cambios en el servidor (por ejemplo, el módulo mod_security), bloqueando el acceso a ciertos puertos (por ejemplo, bloqueando el puerto imap y dejando el puerto imaps abierto), o construyendo mi propio proxy inverso para hacer cumplir estos requisitos .

¿Es esta una buena idea? ¿Todos deberían deshabilitar todas las formas de autenticación de texto simple (donde las credenciales se envían sin cifrar)? Noté que algunas compañías de alojamiento todavía permiten la autenticación de texto simple; ¿Por qué hacen eso? ¿Deberían también deshabilitar la autenticación de texto simple?

    
pregunta Andrew Smith 01.09.2012 - 13:07
fuente

1 respuesta

6

La vulnerabilidad no está en permitir la autenticación de texto simple, sino en usar la autenticación de texto simple. Por ejemplo, un servicio telnet abierto en un sistema Unix no debilita el sistema Unix; las personas que realmente usan ese servicio do lo debilitan.

La naturaleza humana es lo que es, cuando un servicio está disponible, la gente lo usará, por lo que esta es una buena razón para cerrar las puertas desprotegidas en general. Sin embargo, en los servidores my donde todos los usuarios son competentes y confiables (porque solo hay un usuario, yo y yo confío en todas mis personalidades), ocasionalmente creo que vale la pena dejar algunas puertas débiles abiertas, porque podrían ser útiles en algunas situaciones donde la urgencia pasa por alto las salvaguardas de seguridad: por ejemplo, podría iniciar sesión a través de un telnet no protegido porque confío en mí mismo para hacerlo solo en situaciones algo seguras (por ejemplo, de un enlace directo de Ethernet) y aplicar medidas de mitigación (como cambiar mi contraseña inmediatamente después, no es una medida perfecta, lo sé, pero las emergencias son emergencias).

(Su pregunta tiende a suponer que el problema proviene de WiFi, que es una afirmación dudosa: creer que los cables son seguros y, lo que es más, Internet está libre de escuchas ilegales más allá de los puntos de acceso WiFi, me parece una fantasía demasiado optimista.)

    
respondido por el Tom Leek 01.09.2012 - 15:18
fuente

Lea otras preguntas en las etiquetas