net mvc loginurl formsauthentication form cookie asp asp.net forms-authentication

asp.net - mvc - web config forms authentication



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

Imagine que tiene un sitio simple con solo 2 páginas: login.aspx y secret.aspx. Su sitio está protegido usando solo autenticación de formularios ASP.net y un control de servidor de inicio de sesión de ASP.net en login.aspx. Los detalles son los siguientes:

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

Obviamente, hay muchas cosas que considerar con respecto a la seguridad, pero estoy más interesado en la experiencia de código cero que viene con el .NET Framework.

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

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

Aún tiene 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 que participan en el alojamiento del sitio, o en la misma red donde se aloja el sitio
  • seguridad física de las máquinas que alojan el sitio
  • ¿Estás usando las medidas adecuadas para cifrar el tráfico de autenticación? (HTTPS / SSL)

No todos estos problemas son específicos de MS, pero vale la pena mencionarlos porque cualquiera de ellos podría superar fácilmente el problema sobre el que está preguntando, si es que no lo solucionan. 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 exista ningún exploit activo actualmente.

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

No estoy seguro de cuán seguro es esto, pero creo que es seguro, ya que la dificultad para forzar de manera brutal la cadena de identidad.

Parece que funciona más o menos 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.

Bueno, intenta mirar detrás de escena:

Protección de contraseña

Las aplicaciones que almacenan nombres de usuario, contraseñas y otra información de autenticación en una base de datos nunca deben almacenar contraseñas en texto sin formato, por temor a que la base de datos sea robada o comprometida. Con ese fin, SqlMembershipProvider es compatible con tres formatos de almacenamiento ("codificaciones") para contraseñas y respuestas de contraseña. La propiedad PasswordFormat del proveedor, que se inicializa desde el atributo de configuración passwordFormat, determina qué formato se utiliza:

  • MembershipPasswordFormat.Clear, que almacena contraseñas y respuestas de contraseña en texto sin formato.
  • MembershipPasswordFormat.Hashed (valor predeterminado), que almacena hash salados generados a partir de contraseñas y respuestas de contraseña. La sal es un valor aleatorio de 128 bits generado por la clase RNGCryptoServiceProvider de .NET Framework. Cada par de respuestas de contraseña / contraseña se sala con este valor único, y la sal se almacena en el campo PasswordSalt de la tabla aspnet_Membership. El resultado de hash la contraseña y la sal se almacena en el campo Contraseña. Del mismo modo, el resultado de hash la respuesta de contraseña y el salt se almacena en el campo PasswordAnswer.
  • MembershipPasswordFormat.Encrypted, que almacena contraseñas encriptadas y respuestas de contraseñas. SqlMembershipProvider cifra contraseñas y respuestas de contraseña utilizando la clave de cifrado / descifrado simétrica especificada en el atributo decryptionKey de la sección de configuración, y el algoritmo de cifrado especificado en el atributo de descifrado de la sección de configuración. SqlMembershipProvider arroja una excepción si se le pide que encripte las contraseñas y las respuestas de las contraseñas, y si decryptionKey se establece en Autogenerar. Esto evita que una base de datos de membresía que contiene contraseñas encriptadas y respuestas a contraseñas se vuelvan inválidas si se mueven a otro servidor u otra aplicación.

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

  • Si usa texto claro, obviamente es más fácil ingresar a 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 en función de: a) reversiones conocidas de la estrategia de hashing de la clase RNGCryptoServiceProvider yb) acceso a la base de datos para comprometer la sal generada aleatoriamente.

No sé si es posible utilizar algún tipo de tabla arcoiris en el sistema Hash-base predeterminado.

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

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

A menos que utilice SSL, cualquiera 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 jugar 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 toda la sesión de otra persona utilizando secret.aspx, por lo que, en efecto, también tendría acceso al contenido de la página.

Las cookies sobre la URL no son lo suficientemente seguras, hay tantos problemas diferentes (especialmente fugas de referencia si tiene alguna) y el uso de HTTPS.

Por lo que sé, la contraseña se enviará como texto sin formato (pero codificada). Entonces, lo más importante es usar el protocolo HTTPS en las pantallas de inicio de sesión.

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

Si se configura correctamente a través del proveedor de membresía, tendrá un nivel adecuado de seguridad. 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 Security Enterprise . Es posible que desee leer sobre eso y analizarlo cuando implemente la seguridad en su sitio, y solo tenga en cuenta las amenazas de seguridad comunes. Ningún sitio será 100% imposible de descifrar, dado que se encuentra en una red compartida abierta y la seguridad total sería un servidor desconectado encerrado en una caja de seguridad vigilada las 24 horas por los militares (alrededor del nivel de seguridad DoD "A", basado en Orange book ) Pero la funcionalidad lista para usar de los Proveedores de Membresía (cuando está configurada correctamente) ofrecerá una buena cantidad de seguridad.

Editar: 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 detectores de paquetes y monitores de red.