FormsAuthentication: ¿Es seguro?

Question

Usando FormsAuthentication acumulación en asp.net es muy rápida y fácil de crear un sistema de inicio de sesión que crea una cookie para los usuarios autenticados:

FormsAuthentication.SetAuthCookie(uniqueUsername, false); 

En combinación con algo de código en el archivo Web.Config :

<authentication mode="Forms"> 
    <forms loginUrl="Login.aspx" timeout="30" defaultUrl="Dashboard.aspx" protection="All" /> 
</authentication> 
<authorization> 
    <deny users="?" /> 
</authorization> 

Esto se va a recuperar todas las peticiones de vuelta a Login.aspx hasta que el usuario está aprobado y una galleta se crea utilizando la llamada al método SetAuthCookie().

¿Es esto suficientemente seguro?
La regla de oro que uso es que no almaceno ningún dato en el cliente que no me hayan enviado. Entonces, lo que hice en el pasado es mantener el nombre de usuario y la contraseña utilizados en una cookie, y volver a autenticar esto con cada solicitud.

Existe la sobrecarga adicional de volver a autenticar cada vez con este enfoque, pero también significa que no he almacenado ningún dato del servidor en el cliente.

Mi preocupación
Mi preocupación es que al utilizar el método de llamada SetAuthCookie(), que el nombre de usuario se almacena en la máquina cliente. ¿Es posible que alguien rompa el cifrado utilizado y sustituya el nombre de usuario por otro?

Creo que estoy siendo demasiado paranoico y que el tipo y nivel de encriptación que se usa es adecuado, pero pensé que obtendría información de expertos sobre el tema.

Answer 1

Así que lo que he hecho en el pasado es mantener el nombre de usuario y la contraseña utilizada en una cookie, a continuación, volver a esta auténtica con cada petición.

Usted debe no utilizar este enfoque. La contraseña debe no almacenarse en un ticket de autenticación. La razón es que si el ticket de autenticación se ve comprometido, entonces el atacante tiene la contraseña del usuario.Este riesgo puede mitigarse cifrando la cookie del ticket de autenticación, pero supongo que estaba almacenando la cookie en texto sin formato.

Mi preocupación es que al usar la llamada al método SetAuthCookie(), el nombre de usuario se almacena en la máquina del cliente. ¿Es posible que alguien rompa el cifrado utilizado y sustituya el nombre de usuario por otro?

Como señaló Shiraz, la cookie solo se conserva en el equipo cliente si se crea una cookie persistente. (Uno de los parámetros a SetAuthCookie indica si se debe crear o no una cookie.

Incluso si alguien rompiera el esquema de cifrado para modificar la cookie y proporcionar un nombre de usuario diferente, se encontrarían con problemas porque el ticket de autenticación también es digital firmado, lo que significa que ASP.NET puede detectar si el contenido de la cookie se ha modificado. Para falsificar una firma digital, el atacante debería conocer la sal utilizada por el servidor, y si el usuario puede darse cuenta de ello, implica que tiene acceso a el sistema de archivos de su servidor web, por lo que ahora tiene problemas mayores.

Otra cosa que debe entenderse es que el ticket de autenticación tiene un vencimiento, lo que le da una vida útil finita a la validez del ticket. robar un usuario cookies, el tiempo que el atacante tendría que usar ese ticket robado estaría limitado en función del valor timeout que especifique para el sistema de autenticación de formularios (30 minutos de manera predeterminada).

En conclusión, el sistema oficial de autenticación de formularios ASP.NET va a ser mucho más seguro que algo que un desarrollador solitario podrá implementar. Los desarrolladores deben esforzarse por utilizar el sistema de autenticación de formularios en lugar de implementar su propia solución por una miríada de razones, incluida una mejor seguridad, no tener que reinventar la rueda, adoptar prácticas estándar para que otros desarrolladores que se unan al equipo no tengan un aprendizaje tan grande curva para ponerse a la velocidad, y así sucesivamente.

Para obtener más detalles básicos sobre el sistema de autenticación de formularios y cómo está asegurado el ticket, cómo funcionan los diversos ajustes de configuración de <forms>, y así sucesivamente, consulte: Forms Authentication Configuration and Advanced Topics.

Answer 2

Si establece la propiedad DisplayRememberMe en false, la cookie no se conservará en la máquina del cliente. Luego se almacenará en la memoria.

Si usa HTTPS/SSL estará protegido en el camino hacia la máquina del cliente.

Hay, pues, sólo posibilidades teóricas restante:

• romper el cifrado SSL
• robar la cookie de la memoria de la máquina cliente

Seguido de romper el cifrado en la cookie.

Probablemente haya formas más fáciles de atacar su sistema.

http://msdn.microsoft.com/en-us/library/ms998310.aspx

Answer 3

Sólo algunas declaraciones al azar sobre su proceso de pensamiento, pero en lo que respecta a

Así que lo que he hecho en el pasado es mantener el nombre de usuario y la contraseña utilizada en una cookie , a continuación, volver a esta auténtica con cada solicitud.

@Scott Mitchell ya lo mencionó y discutió las razones para no hacerlo debido a las implicaciones de seguridad de esto.

Creo que valdría la pena señalar por qué esto no tendría sentido (incluso sin tener en cuenta las implicaciones de seguridad de la filtración de información). La razón por la que está generando un ticket de autenticación de formularios (la cookie) es que deja que ASP.NET selle este navegador de usuarios con ese ticket que le permite confirmar que este es el usuario especificado que ya se ha autenticado.

Al emitirles un ticket, lo haces para implicar que no necesitan ser autenticados como lo han sido previamente.

Una buena analogía de esto es ir a un bar, en su camino en obtener su identificación escaneada por el gorila para asegurarse de que su identificación es legítima y que tiene más de 21. Tras la confirmación de esto, le dan una pulsera que es de cierto color/diseño.

Con su correa de muñeca, puede salir del edificio para fumar y volver adentro para eludir la línea y la necesidad de tener su identificación escaneada, lo que le permite regresar ese día. Ahora, si te vas a casa, pero no te quitas la pulsera cuando te vayas a la cama (como si dejaras el navegador abierto durante la noche) vuelves al bar al día siguiente e intentas mostrar tu pulsera para evitar la línea. En este punto, eres rechazado porque tienes la pulsera de las últimas noches y te dicen que llegues al final de la línea y te autoricen de nuevo.