¿Cómo realizar una autenticación segura a través de HTTP?

HTTP ordinario de todo tipo no está encriptado. Si desea proteger sus datos, debe enviarlos a través de HTTPS.

Hay un mecanismo para permitir la autenticación segura a través de HTTP sin SSL o TLS, pero rara vez se usa, y aún no es tan bueno como HTTPS. Básicamente, es una medida de seguridad de interés histórico a medias que nunca tuvo éxito, y realmente deberías usar HTTPS de todos modos. Pero como preguntaste .......

El protocolo HTTP admite dos mecanismos de autenticación: Autenticación de acceso básica y de resumen, ambos descritos en RFC 2617 . Estos son mecanismos que hacen que su navegador muestre un cuadro de diálogo de autenticación , no integrado en El contenido de la página. La autenticación básica, que a veces se usa, no es mucho mejor que la transmisión de texto simple.

El mecanismo Digest, sin embargo, es un protocolo de desafío-respuesta. El servidor emite un desafío que contiene un nonce (alguna cadena aleatoria). El cliente debe volver a emitir la solicitud con una respuesta que sea una función hash del nonce y la contraseña (pero no la contraseña en sí).

Hay algunas advertencias importantes:

• El servidor generalmente almacena la contraseña de texto sin formato (o una versión equivalente a texto sin formato de la misma) para poder verificar el desafío. Esto es indeseable, ya que las mejores prácticas exigen que solo se almacenen los hashes de contraseña con sal. (@ user2829759 señala que el servidor también podría almacenar el hash MD5 de (usuario: dominio: contraseña) .
• El mecanismo Digest usa MD5, que se considera un algoritmo hash inseguro en estos días. A diferencia de SSL / TLS, no hay negociación de algoritmo entre el cliente y el servidor.
• No hay verificación de la identidad del servidor. La falsificación es posible, al igual que los ataques de hombre en el medio. Lo único que la Autenticación Digestica es buena para proteger es la propia contraseña, que no es tan útil como se podría pensar.

En Apache, mod_auth_digest .

Una lección que puede extraerse de esta pieza de trivia es que un hackeo de cifrado basado en JavaScript es probable que sufra las mismas debilidades. Si necesita seguridad, simplemente use HTTPS!

Para responder a la pregunta que hiciste : Sí, lo más probable es que las credenciales se envíen de forma clara.

La única vez que Fiddler podría ver el texto en claro para las credenciales, mientras que las credenciales se envían cifradas, es si ha habilitado el proxy SSL en Fiddler y configurado los dispositivos cliente para que confíen en la CA raíz de Fiddler o ignorar los errores del certificado. Probablemente sabrás si has hecho esto.

Para el registro: Confiar en la CA raíz de Fiddler debería solo con fines de prueba, y escribir una aplicación que ignore los errores del certificado es en sí mismo una vulnerabilidad de seguridad.

Dado que está escribiendo una aplicación que se autenticará en un servicio de terceros, un servicio sobre el que presumiblemente no tiene control, no hay nada que pueda hacer para mejorar la seguridad de este proceso de inicio de sesión.

Sería posible que su aplicación se autentique de forma segura a través de HTTP si el sitio web (y su aplicación) implementaran el protocolo SRP (Contraseña remota segura).

Tenga en cuenta que solo sería seguro para las aplicaciones que implementan el protocolo SRP, no para los usuarios que acceden al sitio web con un navegador, ya que si el código JavaScript requerido para hacer que el SRP funcione a través de HTTP, se puede manipular.

Ahora, ya que es muy poco probable que el sitio web con el que está trabajando implemente el protocolo SRP (porque si les importara la seguridad, al menos usarían HTTPS), no puede hacer nada al respecto para asegurar el inicio de sesión proceso.

Además, sería más fácil simplemente cambiar a HTTPS que implementar el protocolo SRP.

Mmm, el problema está en el título de la pregunta "HTTP: inicio de sesión seguro"

"HTTP" y "inicio de sesión seguro" se excluyen mutuamente.

... a menos que agregue una "S" a la anterior :-)

Es probable que el sitio no tenga cifrado o esté débil, por lo que debe tener mucho cuidado al llamar al sitio desde su aplicación web si desea mantener sus contraseñas seguras.

¿Ha intentado buscar una versión encriptada del mismo sitio web?

Hay una extensión jQuery llamada jCryption

enlace

puede cifrar el nombre de usuario / contraseñas con su clave pública ssl y descifrarlo en el servidor con una clave privada. Por lo tanto, estará usando HTTP, pero el inicio de sesión, etc., estaría protegido si se cifran en la computadora cliente usando su público llave.