¿Qué tan segura es la autenticación de formularios básicos en asp.net?

Question

Imagina que tienes un sitio simple con solo 2 páginas: login.aspx y secret.aspx. Su sitio está protegido utilizando únicamente la autenticación de formularios ASP.net y un control del servidor de inicio de sesión de ASP.net en login.aspx. Los detalles son los siguientes:

• El sitio está configurado para usar el SqlMembershipProvider
• El sitio niega a todos los usuarios anónimos
• Las cookies están deshabilitadas

Obviamente, hay muchas cosas a tener en cuenta con respecto a la seguridad, pero estoy más interesado en la experiencia de código cero que viene con el marco .net.

Si, por el bien de esta pregunta, los únicos puntos de ataque son los cuadros de texto de nombre de usuario / contraseña en login.aspx, ¿puede un hacker inyectar un código que les permita acceder a nuestra página secreta.aspx?

¿Qué tan segura es la experiencia inmediata de código cero que ofrece Microsoft?

Answer 1

Todavía tienes algunas variables que no se tienen en cuenta:

• Seguridad en el almacén de datos utilizado por su proveedor de membresía (en este caso, la base de datos del Servidor SQL).
• seguridad de otros sitios alojados en el mismo IIS
• seguridad general de la red de las máquinas involucradas en el alojamiento del sitio, o en la misma red donde está alojado el sitio
• seguridad física de las máquinas que alojan el sitio
• ¿Está utilizando las medidas adecuadas para cifrar el tráfico de autenticación? (HTTPS / SSL)

No todos estos problemas son específicos de la EM, pero vale la pena mencionarlos porque cualquiera de ellos podría superar fácilmente el problema que está preguntando, si no se resuelve. Pero, para el propósito de su pregunta, asumiré que no hay ningún problema con ellos.

En ese caso, estoy bastante seguro de que la autenticación de formularios hace lo que se supone que debe hacer. No creo que haya ningún exploit actualmente activo por ahí.

Answer 2

Hasta donde yo sé, la contraseña se enviará como texto sin formato (pero codificado). Entonces, lo más importante es utilizar el protocolo HTTPS en las pantallas de inicio de sesión.

La otra configuración parece ser segura para mí.

Answer 3

Con la autenticación básica HTTP, que es lo que utiliza la autenticación de formularios básicos .NET, para ver la página secr.aspx, el navegador debe enviar una concatenación codificada en Base64 del nombre de usuario y la contraseña.

A menos que utilice SSL, cualquier persona que tenga acceso para escanear la red entre el servidor y el navegador puede leer esta información. Pueden decodificar el nombre de usuario y la contraseña. Pueden volver a reproducir el nombre de usuario y la contraseña en el futuro para obtener acceso a la página secret.aspx.

Dicho esto, a menos que use SSL, alguien también puede escanear la sesión completa de otra persona utilizando secret.aspx, por lo que, en efecto, también tendrían acceso al contenido de la página.

Answer 4

Bueno, intenta mirar detrás de escena:

  

Protección con contraseña

     

Aplicaciones que almacenan nombres de usuario,   contraseñas y otra autenticación   La información en una base de datos nunca debe   almacenar contraseñas en texto sin formato, para que no   La base de datos puede ser robada o comprometida. A   ese fin, SqlMembershipProvider   admite tres formatos de almacenamiento   (" codificaciones ") para contraseñas y   respuestas de contraseña El proveedor   Propiedad PasswordFormat, que es   inicializado desde el passwordFormat   atributo de configuración, determina   qué formato se utiliza:

     

  
• MembershipPasswordFormat.Clear, que almacena contraseñas y contraseñas   respuestas en texto simple.
  
• MembershipPasswordFormat.Hashed (el valor predeterminado), que almacena salado   hashes generados a partir de contraseñas y   respuestas de contraseña La sal es un azar.   Valor de 128 bits generado por .NET   RNGCryptoServiceProvider de Framework   clase. Cada contraseña / contraseña responde   El par es salado con este valor único,   y la sal se almacena en el   aspnet_Membership table's PasswordSalt   campo. El resultado del hashing del   contraseña y la sal se almacena en el   Campo de contraseña. Del mismo modo, el resultado   de hash la respuesta de contraseña y el   sal se almacena en el PasswordAnswer   campo.
  
• MembershipPasswordFormat.Encrypted,   que almacena contraseñas cifradas y   respuestas de contraseña   SqlMembershipProvider cifra   contraseñas y respuestas de contraseña usando   El cifrado / descifrado simétrico   clave especificada en el   descifrado de la sección de configuración   atributo, y el cifrado   algoritmo especificado en el    sección de configuración   atributo de descifrado.   SqlMembershipProvider lanza un   excepción si se le pide que cifre   contraseñas y respuestas de contraseñas, y si   decryptionKey está configurado en Autogenerar.   Esto evita una base de datos de membresía   que contiene contraseñas cifradas y   las respuestas de contraseña se vuelven inválidas   si se trasladó a otro servidor u otro   aplicación.
  

Entonces, la fortaleza de su seguridad (lista para usar) dependerá de la estrategia de formato de protección de contraseña que esté utilizando:

• Si usa texto claro, obviamente es más fácil hackear su sistema.
• Usando Encrypted por otro lado, la seguridad dependerá del acceso físico a su máquina (o al menos, machine.config).
• El uso de contraseñas hash (el valor predeterminado) garantizará la seguridad dependiendo de: a) reversiones conocidas de la estrategia de hash de la clase RNGCryptoServiceProvider yb) acceso a la base de datos para comprometer la sal generada aleatoriamente.

No sé si es posible usar algún tipo de pirateo de la tabla del arco iris en el sistema Hash-base predeterminado.

Para más detalles, consulte este enlace: http://msdn.microsoft.com/en-us/library/aa478949. aspx

Answer 5

Si se configura correctamente a través del proveedor de membresía, tendrá un nivel de seguridad adecuado. Fuera de eso, el acceso a esa página podría ser accesible a través de ataques canónicos, pero eso tiene que ver con su seguridad general. Hice una presentación sobre el uso de los Bloques de aplicaciones de seguridad empresarial . Es posible que desee leer sobre ellos y examinarlos al implementar la seguridad en su sitio, y simplemente estar al tanto de las amenazas de seguridad comunes. Ningún sitio será 100% inhabilitable, dado que usted está en una red compartida abierta y la seguridad total sería un servidor desenchufado encerrado en una caja fuerte vigilada las 24 horas del día, los 7 días de la semana (alrededor del DoD "seguridad de nivel A", basado en Orange libro). Pero la funcionalidad lista para usar de los Proveedores de Membresía (cuando se configura correctamente) ofrecerá una buena cantidad de seguridad.

Edit: Sí, estoy de acuerdo con el otro comentario que se hizo, HTTPS en al menos las pantallas de inicio de sesión es un hecho, si desea proteger el nombre de usuario / contraseñas de los rastreadores de paquetes y monitores de red.

Answer 6

Asp.Net admite sesiones sin cookies, como esta publicación de blog muestra . En lugar de una cookie de sesión, utiliza un identificador en la url para rastrear a los usuarios.

No estoy seguro de qué tan seguro es esto, pero creo que es seguro ya que la dificultad de fuerza bruta fuerza la cadena de identidad.

Parece que funciona más o menos fuera de la caja, sin embargo, al redirigir a un usuario y querer mantener el estado de la sesión, debe incluir la identificación de la sesión. La publicación del blog muestra cómo hacerlo, así como muchos otros artículos en la web.

Answer 7

Aquí hay dos buenos artículos de Microsoft sobre el tema:

Cómo: Proteger la autenticación de formularios en ASP.NET 2.0

INFORMACIÓN: Ayude a la autenticación segura de formularios usando una capa de sockets segura (SSL)

Answer 8

Las cookies sobre URL no son lo suficientemente seguras, existen muchos problemas diferentes (especialmente la fuga de referencias si tiene alguna) y el uso de HTTPS.