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

Question

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 utilizar el SqlMembershipProvider
• El sitio niega todos los usuarios anónimos
• cookies están desactivadas

El obviamente muchas cosas a tener en cuenta en materia de 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 código que les permita acceder a nuestra página secret.aspx?

¿Cuán segura es la experiencia de código cero de Microsoft?

Answer 1

todavía tiene algunas variables que no se contabilizan:

• Seguridad en el almacén de datos utilizado por el proveedor de pertenencia (en este caso, la base de datos SQL Server).
• seguridad de otros sitios alojados en el mismo IIS
• seguridad de la red general de las máquinas involucradas en la organización del sitio, o en la misma red que el sitio está alojado
• 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 MS, pero vale la pena mencionarlos, ya que cualquiera de ellos podría superar fácilmente el problema por el que está preguntando, si no lo hace. 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.

Answer 2

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í.

Answer 3

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 del Security Enterprise Application Blocks. 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.

Answer 4

Asp.Net admite sesiones sin cookies, como this blog post shows. En lugar de una cookie de sesión, usa un identificador en la url para rastrear usuarios.

No estoy seguro de qué tan seguro es esto, pero creo que es una forma segura como la dificultad para forzar a la fuerza la cadena de identidad.

Parece que funciona más o menos de fábrica, 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 5

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, cualquier persona que tenga acceso para explorar 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ían acceso al contenido de la página.

Answer 6

Bueno, tratar de mirar detrás de las escenas:

protección con contraseña

aplicaciones que almacenan nombres de usuario, contraseñas y otra información de autenticación en una base de datos deben nunca almacenar contraseñas en texto sin formato, no sea que la base de datos sea robada o comprometida. A ese extremo, SqlMembershipProvider admite tres formatos de almacenamiento ("codificaciones") para las contraseñas y respuestas de contraseña. propiedad PasswordFormat del proveedor, que se inicializado desde el atributo de configuración passwordFormat , determina qué formato se utiliza:

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

lo tanto la fuerza de su seguridad (de la caja) dependerá de qué contraseña estrategia de formato de protección que está utilizando:

• Si utiliza un texto claro, obviamente es más fácil de cortar en tu sistema.
• Al usar Encriptado, 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 hashing de la clase RNGCryptoServiceProvider yb) el 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 más detalles, echa un vistazo a este enlace: http://msdn.microsoft.com/en-us/library/aa478949.aspx

Answer 7

Éstos son dos buenos artículos de Microsoft sobre el tema:

How To: Protect Forms Authentication in ASP.NET 2.0

INFO: Help Secure Forms Authentication by Using Secure Sockets Layer (SSL)

Answer 8

galletas más de URL no es segura basta, hay tantos problemas diferentes (especialmente fugas de referencia si tiene alguna) y uso de HTTPS.