¿Cuáles son los vectores de ataque para las contraseñas enviadas a través de http?

Estoy tratando de convencer a un cliente de que pague SSL por un sitio web que requiere inicio de sesión. Quiero asegurarme de que entiendo correctamente los principales escenarios en los que alguien puede ver las contraseñas que se envían.

Tengo entendido que en cualquiera de los saltos en el camino puede usar un analizador de paquetes para ver lo que se está enviando. Esto parece requerir que cualquier hacker (o su malware / botnet) esté en la misma subred que cualquiera de los saltos que toma el paquete para llegar a su destino. ¿Está bien?

Suponiendo que algo de este requisito de subred sea cierto, ¿debo preocuparme por todos los saltos o solo por el primero? Obviamente, puedo preocuparme por el primero si están en una red Wifi pública, ya que cualquiera podría estar escuchando. ¿Debería preocuparme por lo que sucede en las subredes que los paquetes atravesarán fuera de esto? No sé mucho sobre el tráfico de red, pero supongo que fluye a través de los centros de datos de los principales operadores y que no hay muchos vectores de ataque jugosos allí, pero corríjame si estoy equivocado.

¿Hay otros vectores de los que preocuparse fuera de alguien que escucha con un analizador de paquetes?

Soy un novato en redes y seguridad, así que no dude en aclararme si estoy usando la terminología incorrecta en algo de esto.

Algo para tener en cuenta que otros no han mencionado aquí es que algunos navegadores almacenan en caché sus datos de formulario. El comportamiento predeterminado en los sitios SSL generalmente es no almacenar en caché nada a menos que elija "guardar mi contraseña". Por lo general, los campos de contraseña no se almacenan en caché de todos modos, pero he visto algunas rarezas (por lo general, la información de la tarjeta de crédito, que sé que no es realmente el tema de la pregunta).

La otra cosa a tener en cuenta es que el cifrado SSL comienza en el protocolo de enlace TCP. Una vez bajo SSL, no puede distinguir HTTP sobre SSL de FTP sobre SSL (aparte de los supuestos realizados a través del número de puerto).

Tampoco puede distinguir una solicitud de inicio de sesión de una solicitud de "Solo estoy navegando", esto ofusca el flujo de la página de los posibles piratas informáticos y también asegura que no solo sus datos de contraseña estén seguros, sino también su historial de navegación / datos de cookies / y cualquier información personal que acompaña a su cuenta.

En general, si elimina los ataques de hombre en el medio del espectro que reduce muchos de los posibles ataques, eso no quiere decir que su sitio sea "seguro". Además, la política de zonificación debería ayudarlo a protegerse de los ataques XSS, ya que hará un cambio de zona si su usuario es redirigido fuera de su sitio.

Los datos son vulnerables en cualquier lugar de la ruta, no solo en la primera o la última etapa. Es bastante concebible que un sistema involucrado en la transferencia busque nombres de usuario, contraseñas y otros datos confidenciales. Por lo tanto, se deduce que los datos confidenciales solo deben viajar a través de un enlace que está asegurado todo el camino y, por supuesto, para eso es exactamente SSL. Dependiendo de qué datos estén involucrados, puede haber leyes locales que dicten SSL.

Hay servidores proxy que pueden almacenar datos.

Pero también existe la obligación de mantener seguras las contraseñas de los usuarios. Muchos usuarios usan un conjunto limitado de contraseñas, por lo que un sitio inseguro puede comprometer la contraseña de su banco de origen, por ejemplo.

Su análisis es razonable, en mi humilde opinión.

Lo que hay que tener en cuenta, supongo, es que podría haber cachés en su camino. Por lo tanto, es posible que la solicitud se registre en algún lugar (especialmente si el inicio de sesión es más de GET, lo que sería terrible).

Probablemente, lo que hay que tener en cuenta es que la mayoría del acceso a la red tiene lugar en un área donde hay muchas otras personas en la misma red. Trabajo / Uni / Escuela son los principales ejemplos. En casa se podría argumentar que es menos riesgoso, porque solo debes preocuparte por los caminos hacia arriba.

Pero realmente, no hay duda aquí. Usas SSL cuando inicias sesión. Probablemente el argumento más convincente para el chico sea que hace que tu sitio web parezca más confiable, ya que, idealmente, el público en general nunca iniciaría sesión en un sitio que no tiene una pantalla de inicio de sesión basada en SSL .

Pero seamos realistas. Es casi seguro que este vector de ataque no es la forma en que su sistema o usuarios se verán comprometidos.

HTH

Estoy de acuerdo con las reflexiones de KevinM para responder sus propias preguntas, y John Gardeniers está apuntando en la dirección correcta. También debo estar de acuerdo con lo que sedoso dijo, "idealmente, el público en general nunca iniciaría sesión en un sitio que no tenga una pantalla de inicio de sesión basada en SSL", y señalar que este no es el caso contemporáneo en absoluto.

No estoy de acuerdo con el tono sedoso (probablemente involuntario), que conduce a la percepción omnipresente de que "el público en general" es estúpido. El cliente de KevinM claramente no tiene un concepto de necesidad de SSL, y esa es la persona promedio en pocas palabras. No son estúpidos, simplemente no lo saben. Decir "necesitas esto", provocará la respuesta, "He vivido x años sin él, y viviré x más bien", o tal vez incluso una respuesta peor, "Odio que me digan lo que necesito". ". ¡Así que ten cuidado!

Tu preocupación es legítima, Kevin. Su cliente necesita un certificado SSL. Creo que su verdadera preocupación debería ser cómo venderlos. No solo se preocupan los inicios de sesión de los usuarios, sino también los inicios de sesión de administrador y operador que también se beneficiarían de estar protegidos por SSL.

Sí, hay otras cosas de las que preocuparse a este respecto, incluso más que el rastreo de paquetes, como XSS . Son numerosos y están bien documentados .

en toda la ruta seguida de paquete, si se puede rastrear sobre HTTP y se pueden ver los datos ... incluso si usa HTTP en Proxy como TOR ... usando el ataque de cosecha, etc. se puede engañar al Proxy para que filtre los paquetes de datos ... así que si hay algo cerca de confidenciales (contraseñas, datos personales, imágenes privadas, etc.) ... solo es adecuado transferirlos a través de HTTPS.

Eso también, incluso HTTPS es vulnerable con una implementación incorrecta y hay varios ataques SSL aplicables sobre él ... aún así se pueden evitar con una implementación cuidadosa.

Pero, usar HTTP para texto plano es como invitar incluso a los novatos n / w niños a rastrear las contraseñas.