¿Se puede cifrar (sin SSL) una autenticación mediante HTTP a través de IIS?

Question

Estoy acostumbrado a los servidores * nix y si queríamos una pantalla de inicio de sesión totalmente segura, (hasta donde yo sé) usar SSL a través de HTTPS. Nuestra organización de supervisión en el trabajo utiliza servidores de Windows para servir páginas web. En una de esas páginas están autenticando credenciales de red. Esta página está utilizando HTTP, y aparece como como autenticación básica (un cuadro de diálogo emergente) para un Administrador de informes de SQL Server.

Dicen que Basic está deshabilitado en IIS.

En mi experiencia limitada con IIS en la universidad, creo que (creo que) los subdominios pueden anular la configuración general. Creen que está utilizando la Autenticación de Windows integrada.

Entonces ...

1. ¿Hay una manera de diferenciar entre autenticación básica y autenticación integrada de Windows durante la visualización de un indicador de página web, y ...

2. ¿Es posible cifrar la comunicación entre la computadora y el servidor durante la autenticación para que el texto que se envía esté encriptado (sin una solución JS)?

Answer 1

Tanto la autenticación integrada básica como la de Windows envían las credenciales sin cifrar por el cable. Si el cuadro de inicio de sesión emergente tiene el nombre del navegador y se parece a una ventana estándar, es Básico o Integrado. Si el nombre de usuario/contraseña utilizado para obtener acceso es el mismo que el de la cuenta de dominio del usuario, es Windows Integrated. Puede confirmar olfateando la transmisión HTTP con Fiddler.

No existe una buena forma práctica de encriptar esas credenciales en ambos casos sin SSL. Here es un buen artículo sobre por qué los métodos de seguridad personalizados son una mala idea, y SSL es el camino a seguir.

Answer 2

También podría usar HTTP Digest authentication, que cifrará la autenticación en el encabezado HTTP (incluso sin SSL). Esto mostrará un cuadro de diálogo similar al que obtienes con la autenticación HTTP básica. Hay un par de inconvenientes:

• mayoría de los navegadores utilizan el mismo cuadro de diálogo para básico y digerir autenticación, de modo que un usuario, realmente no sabe cuál es el uso de .
• Sólo se encripta la autenticación, man-in-the-middle que podría interceptar y alterar el intercambio podría reemplazar el contenido de las solicitudes utilizando esas credenciales.

Por estas razones, SSL es mejor (como se sugirió anteriormente).