2009-04-03 16 views

Respuesta

5

HTTP digest authentication (que es una bestia bastante diferente de la autenticación básica HTTP) es bastante seguro sobre HTTP directo, y no es difícil de implementar en el servidor. No se envía nada por el cable que pueda revelar cuál es la contraseña, solo información que permite al cliente demostrarle al servidor que tiene la contraseña correcta.

Si desea una explicación decente sobre cómo implementar la autenticación resumida HTTP en su aplicación, Paul James has an excellent article on it.

El único problema real con la autenticación HTTP está en los navegadores mismos: la interfaz de usuario es terrible, pero puede ser overcome with some Javascript.

1

autenticación HTTP no es inseguro cuando se utiliza HTTPS. autenticación básica

+0

Corrección: la autenticación HTTP al usar HTTPS es tan segura como la sesión SSL. – Randolpho

+0

No puede implementar la funcionalidad de cierre de sesión en Basic Auth, eso es bastante basura :) –

+0

Para Firefox, vea estos errores: https://bugzilla.mozilla.org/show_bug.cgi?id=55181 y https: //bugzilla.mozilla .org/show_bug.cgi? id = 287957. Pero sí, estoy de acuerdo. –

2

HTTP es perfectamente seguro cuando se usa con un SSL (https: //) desde el sitio web se cifrará todo el tráfico HTTP que incluye las credenciales. Sin embargo, un inconveniente subjetivo es que al usar este método, los usuarios deberán interactuar con la ventana emergente de autenticación de su navegador para iniciar sesión en su sitio.

+0

Por lo tanto, cabe suponer que los principales sitios web no utilizan HTTP auth porque SSL consume muchos recursos en ambos extremos. ¿Por qué el usuario podría interactuar con la ventana emergente de autenticación como un problema? Si tuvieran una discapacidad, ¿no tendrían ya mecanismos para superar este problema? –

+0

Sin SSL, cualquier forma de autenticación web es menos segura, por lo que la decisión tiene más que ver con el nivel de seguridad necesario al iniciar sesión y menos con el tipo de autenticación que se utiliza. La preocupación emergente del navegador se trata principalmente de diseño del sitio, ya que puede parecer fuera de lugar y ser discordante para los usuarios –

0

Al utilizar https, también se puede instalar un certificado en el navegador del cliente y verificar que. myopenid ofrece esto para sus cuentas OpenID. Tengo uno y funciona muy bien (desde el punto de vista del cliente).

2

Para que quede claro, la única manera de hacerlo es a través de HTTPS.

Pero, ya que supongo que esto no es una opción, y también supongo que busca un sistema de "inicio de sesión completamente gestionada", continúo:




Aparte de HTTPS es posible el uso de JavaScript para hacer hashing seguro de contraseñas en el lado del cliente, para evitar revelar contraseñas de texto sin formato sobre la marcha, pero esto es solo una solución a medias.

Los problemas con este enfoque son:

  1. ataque a una repetición sigue siendo una opción viable.
  2. Solo los usuarios con JavaScript habilitado podrían autenticar de esta manera.




Otro enfoque es un mecanismo de desafío/respuesta más complicada:

  1. Enviar un "Challenge" junto con la página de inicio de sesión.
  2. Calcula el hash del lado del cliente Password + Challenge.
  3. Enviar el nombre de usuario.
  4. Calcular el hash de la contraseña + Challenge (que no deben confiar en la solicitud de página) en el lado del servidor, y comparar.

Y los problemas con que:

  1. Sólo los usuarios con Javascript habilitado sería capaz de auth de esta manera.
  2. La contraseña de texto deben ser almacenados en el servidor para validar la respuesta al desafío, y deben ser codificados en el disco o protegido de otra manera.




Ahora, para ser justos, el problema # 2 no es tan grande de un peligro como suena. De hecho, cuando en su lugar utilizas la autenticación HASH, el hash se eleva al nivel de "clave".



En este punto es bastante seguro de usar cookies para almacenar un ReferrenceID inicio de sesión generada aleatoriamente, similar a su ID de sesión, pero el servidor lo desea, puede cifrar utilizando la IP referencia como parte del IV o la tecla para evitar que otros usuarios pirateen el ReferrenceID.

De todos modos, espero que proporcione un poco de dirección en el camino de su diseño.

0

El uso de SSL para el cifrado en combinación con HttpOnly Cookies para ayudar a prevenir XSS es su mejor opción para usar cookies. No voy a decir que es a prueba de balas, sin embargo.

+0

No protegerá contra XSS, lo hará más difícil de explotar. –

+0

pero todavía se puede aprovechar con un canal interactivo XSS. Eche un vistazo a BeeF, BrowserRaider, XSS Shell y XSS Tunneling –

+0

Gracias por el comentario. Actualicé mi respuesta. –

1

En primer lugar, HTTP Auth es seguro sobre SSL que no sea el hecho de que no se puede implementar una verdadera funcionalidad de "Cerrar sesión". El usuario debe cerrar su navegador, lo cual es bastante malo.

En segundo lugar, debe usar HTTPS en todos los casos para que sea seguro, después de eso, tiene Basic Auth cosas similares como "Digest" y "NTLM Auth".

Cuestiones relacionadas