CMS usa http y así envía la contraseña en texto sin formato

Tienes que usar https. Esto no es responsabilidad de la aplicación de CMS, sino de la persona que implementa el sistema, comprar un certificado SSL firmado de una autoridad certificadora de confianza conocida (tenga en cuenta que puede comprar gratis en enlace o incluido en el costo de registro de su dominio en, digamos enlace ) y obligue a que todo el tráfico sea solo enviado a través de HTTPS.

Incluso si la aplicación CMS dice hash de su contraseña del lado del cliente (usando say javascript), envió la contraseña de hash a través de la red y luego verificó el hash del lado del servidor, la contraseña de hash (por ejemplo, hash=bcrypt('Correct Horse Battery Staple', salt)= '$2a$14$XUgYF0o3flsoGam2GHiw8OlQv9BBR/ihAwS/k83fZk.YjJ1hA/04.' )  todavía se enviaría en texto sin formato para que cualquiera pueda escuchar a escondidas. Estos intrusos aún podrían realizar un ataque de reproducción (por ejemplo, modificar el javascript del lado del cliente para que, en lugar de codificar una contraseña ingresada, simplemente enviar de vuelta la contraseña de hash capturada $2a$14$XUgYF0o3flsoGam2GHiw8OlQv9BBR/ihAwS/k83fZk.YjJ1hA/04. ) que interceptaron. Además, tenga en cuenta que esto convierte efectivamente la contraseña con hash del lado del cliente en la contraseña efectiva; así que lo ideal sería que además añadiera más hash al lado del servidor hash recibido para comparar con lo que está almacenado en la base de datos. O simplemente podrían interceptar las cookies de sesión enviadas a través de la red y usarlas para imitar la actividad de un usuario que haya iniciado sesión actualmente.

O simplemente podrían hacer un lío con el enrutamiento para hacer un hombre en el ataque central, así que envías la contraseña a su servidor.

Además, si requieren que use SSL sin haber comprado un certificado, los usuarios pueden asustarse debido a las advertencias del navegador de un certificado que no es de confianza.

Un esquema más complicado puede convencerte de que hay más seguridad de la que realmente existe, aunque sería trivial que un atacante pudiera eludir. Todo lo que se requiere es configurarlo utilizando HTTPS.

Bueno, Joomla es una aplicación web, no es responsabilidad de la aplicación web proporcionar una interfaz SSL para que pueda usar HTTPS. Esta tarea es para el servidor web en el que se está ejecutando la aplicación web.

Joomla ha tenido un ajuste "Forzar SSL" desde la versión 1.5. Puede configurarlo cambiando el archivo configuration.php o usando la GUI web del administrador .

Se establece en "Ninguno" de forma predeterminada, principalmente porque varios hosts no admiten SSL / HTTPS de forma inmediata. Probablemente desee cambiarlo a "Solo administrador" para proteger solo la interfaz de administración, o "Sitio completo" si desea proteger incluso el frente público (es útil si tiene inicios de sesión frontales).

El envío de contraseñas a sitios web en texto sin formato (por ejemplo, un formulario de inicio de sesión HTML estándar en un CMS, foro u otro script web) no es seguro. De manera similar, el envío de contraseñas en correos electrónicos (ya sea uno nuevo como "reinicio" o no) es inseguro. Cada vez que una contraseña está en texto sin formato, es insegura.

La pregunta es si la cuenta (y el sitio) es lo suficientemente importante como para garantizar SSL para cifrar la contraseña en tránsito: la seguridad siempre es una compensación entre el bloqueo y la facilidad de uso y su "apetito de riesgo".

Para el foro de Joe Bloggs para él y sus amigos, asumiendo que cada uno de ellos sigue una práctica de seguridad decente y tiene una contraseña única que no han reutilizado en otros sitios (!), entonces el nivel de interés de un pirata informático va a ser muy bajo Para rastrear esa contraseña, deben estar en un salto entre el usuario y el servidor, lo que generalmente es una tarea de alto esfuerzo para las cuentas de bajo valor (le permite ingresar al foro). Si reutilizan las contraseñas, el valor de cada cuenta aumenta, pero el tamaño del transporte es relativamente bajo en comparación con un simple ataque de phishing en cuentas bancarias o redes sociales.

Si desea contraseñas que están cifradas antes del tránsito y no son susceptibles de ataques repetidos, entonces necesita usar algo como Apache's mod_auth_digest , que utiliza un mecanismo de desafío-respuesta. Su CMS u otro script puede tener un complemento o "MOD" que habilite esta opción.

No hay una solución similar para las contraseñas en los correos electrónicos: una vez que se envían, se trata de texto sin formato y no se puede hacer nada al respecto **. Simplemente no lo hagas!

Consulte PlainTextOffenders.com para ver ejemplos de malas prácticas de "contraseñas en correos electrónicos", junto con historias relacionadas de prácticas peores que se hacen evidentes en los correos electrónicos. .

.

.

** Esto ignora la opción del cifrado PGP, pero eso requiere la clave PGP pública del destinatario para que pueda cifrarlo solo para sus ojos, a los que los scripts generalmente no tendrán acceso y muchos usuarios ni siquiera lo tendrán configurado.