¿Cómo se roban las contraseñas en una conexión no SSL?

20

Me siento avergonzado de hacer esta pregunta después de haber trabajado en el campo durante 20 años, pero ¿puede alguien explicarme por qué debo ejecutar SSL en cualquier sitio web que use autenticación? Comprendo los problemas más importantes de "por qué" (las personas usan la misma contraseña en el blog y en el banco) y supongo que las contraseñas se almacenan encriptadas en la base de datos del sitio, pero quiero, simplemente, explicar el riesgo técnico de transmitir sin SSL Contraseñas de una manera que se basa en la aplicación práctica.

Ejemplo: tengo un blog de wordpress que estoy hospedando en bluehost. Accedo a la página de inicio de sesión, ingresé mi nombre de usuario y contraseña y presioné enviar. Esa información se envía al servidor web en un POST HTTP sin cifrar.

Ahora, si alguien está en mi red o en cualquier red donde se transmiten los paquetes, ejecutando un sniffer, pueden leer los paquetes y escribir el código para analizar palabras interesantes como "inicio de sesión" o "contraseña". ¿Es así como funciona?

¿Cómo funcionaría esto en mi ejemplo? Supongamos que no hay nadie en mi red doméstica; de lo contrario, he tomado las medidas de seguridad adecuadas para los dispositivos que están bajo mi control. ¿Cómo se interpone el hacker entre mi sitio web y yo? ¿Podría simplemente iniciar sesión en su propia cuenta de bluehost y poder monitorear todo el tráfico en la subred? O podrían estar EN CUALQUIER LUGAR en el medio; p.ej. Estoy en FIOS de Verizon, por lo que tal vez ingresen (instalen un proceso automatizado) a un servidor en algún lugar dentro de la red de Verizon. ¿O podrían estar literalmente en cualquier lugar?

Mi comprensión de las redes es que mi dispositivo transmite paquetes con una IP de destino que es el servidor de bluehost. Esos paquetes se "notan" y mi enrutador los reenvía a enrutadores y conmutadores ascendentes que forman parte de la red de Verizon. A medida que cruzan cada subred, existe la posibilidad de que cualquier dispositivo que se encuentre en esa red observe el paquete, ya que se transmite localmente. Las buenas prácticas tendrían esas redes configuradas con una seguridad que no permitiera que las personas pudieran ponerse en el medio ... pero una vez que la información llega a bluehost, estamos a su merced en términos de paquetes de transmisión. Una vez que el servidor http "escucha" la información PUBLICADA, se cifra y se compara con la contraseña cifrada localmente.

¿Es esta una forma precisa de pensarlo y explicárselo a los demás?

    
pregunta DaveA 10.04.2014 - 18:30
fuente

1 respuesta

26

Cuando los datos se intercambian a través de Internet, saltan de enrutador a enrutador, comenzando con la fuente (su computadora de escritorio) y terminando con el destino (el servidor de autenticación al que está enviando la contraseña). Todos los enrutadores, por definición, "ven" los datos. Además, todas las máquinas que están directamente conectadas con el enlace entre cualquiera de los dos enrutadores también pueden ver los datos.

En la práctica, para los atacantes de bajo nivel, la detección de contraseñas se produce principalmente a través de tres mecanismos:

  1. Cerca del usuario (usted). P.ej. está utilizando su computadora portátil y se está conectando a través de un punto de acceso WiFi; Otras máquinas conectadas al mismo punto de acceso ven todo su tráfico. Tenga en cuenta que "tomar medidas" para evitar que los atacantes locales puedan ser bastante difíciles (por ejemplo, olvídese que WiFi está involucrado).

  2. Cerca del servidor. Normalmente, los servidores están alojados en masa en algunas instalaciones compartidas, y los propietarios de servidores poco delicados pueden espiar a sus vecinos. Si esto es posible o incluso sencillo, depende mucho de la competencia de los administradores de red en el sitio de alojamiento.

  3. A través de la redirección activa. Cuando desea conectarse a un servidor , realmente escribe un nombre y luego DNS encuentra la dirección IP que corresponde a ese nombre. Su máquina enviará los paquetes a esa dirección IP. Sin embargo, el DNS, en general, está mal protegido y puede ser modificado por un individuo malintencionado. Un malvado puede entonces redirigir sus paquetes de forma transparente a sus propias máquinas; incluso puede inspeccionar los datos, pero seguir enviándolos a su verdadero destino, lo que lo convierte en un Man-in-the -Middle . En ese momento, el atacante ve todos los datos, incluida la contraseña y lo que protege la contraseña, y puede secuestrar la conexión en cualquier momento.

Los tres tipos de inhalación pueden ponerse en práctica, y en realidad son aplicados por estudiantes con unos pocos cientos de dólares de presupuesto y una falta de moralidad. Los delincuentes más avanzados pueden emplear otros métodos activos, por ejemplo, tratando de perturbar mecanismos de enrutamiento dinámico . O simplemente sobornar a los empleados en las instalaciones de la red (en particular, los proveedores de servicios de Internet).

SSL (ahora conocido como "TLS") corrige las cosas de varias maneras:

  • Encripta todos los datos con una clave que solo los dos puntos finales (su máquina y el servidor) conocen, con lo que se mantienen alejados los escuchas pasivos.
  • Utiliza el certificado del servidor, de modo que el cliente puede tener cierta confianza de que, de hecho, está hablando con el servidor original deseado, no con un falso controlado por un atacante. Este es el punto de la imagen del candado y las advertencias de miedo en los navegadores web.
  • SSL garantiza una integridad continua, lo que significa que un atacante activo no puede simplemente ponerse en la posición MitM, reenviar los bytes de datos y luego secuestrar la conexión después de que se haya realizado la autenticación. La protección otorgada por SSL es tanto para confidencialidad (los datos son ilegibles para los forasteros) como para integridad (los datos no pueden ser alterados por los forasteros), y esto abarca la conexión completa, no solo los pasos iniciales.

Con SSL activo y sin problemas de validación de certificados, puede enviar su contraseña con una garantía razonable de que solo el servidor deseado la verá. La forma en que el servidor verifica la contraseña es irrelevante aquí. Además, y de nuevo gracias a SSL, el servidor puede asumir que la autenticación inicial es válida para todo el tráfico posterior en la misma conexión, porque SSL garantiza que estará hablando con el mismo cliente todo el tiempo.

    
respondido por el Thomas Pornin 10.04.2014 - 19:12
fuente

Lea otras preguntas en las etiquetas