Al observar la identidad de ASP.NET (nueva implementación de membresía en ASP.NET), me encontré con esta interfaz al implementar la mía propia UserStore:

//Microsoft.AspNet.Identity.Core.dll

namespace Microsoft.AspNet.Identity
{ 
    public interface IUserSecurityStampStore<TUser> :
    {
        // Methods
        Task<string> GetSecurityStampAsync(TUser user);
        Task SetSecurityStampAsync(TUser user, string stamp);
    }
}

IUserSecurityStampStorese implementa por defecto EntityFramework.UserStore<TUser>que esencialmente obtiene y establece la TUser.SecurityStamppropiedad.

Después de un poco más de excavación, parece que a SecurityStampes una Guidnueva generación en puntos clave de UserManager(por ejemplo, cambiar las contraseñas).

Realmente no puedo descifrar mucho más allá de esto ya que estoy examinando este código en Reflector . Casi toda la información de símbolos y asíncronos se ha optimizado.

Además, Google no ha sido de mucha ayuda.

Las preguntas son:

• ¿Qué es una SecurityStampidentidad ASP.NET y para qué se utiliza?
• ¿ SecurityStampJuega algún papel cuando se crean las cookies de autenticación?
• ¿Hay alguna ramificación de seguridad o precaución que deba tomarse con esto? Por ejemplo, ¿no envía este valor en sentido descendente a los clientes?

Actualización (16/09/2014)

Código fuente disponible aquí:

• https://github.com/aspnet/Identity/
• https://github.com/aspnet/Security/

Esto está destinado a representar la instantánea actual de las credenciales de su usuario. Entonces, si nada cambia, el sello permanecerá igual. Pero si se cambia la contraseña del usuario, o si se elimina un inicio de sesión (desvincula su cuenta de google / fb), el sello cambiará. Esto es necesario para cosas como firmar automáticamente usuarios / rechazar cookies antiguas cuando esto ocurre, que es una característica que viene en 2.0.

La identidad aún no es de código abierto, todavía está en proceso.

Editar: actualizado para 2.0.0. Por lo tanto, el objetivo principal de la SecurityStampes permitir cerrar sesión en todas partes. La idea básica es que siempre que se cambie algo relacionado con la seguridad en el usuario, como una contraseña, es una buena idea invalidar automáticamente cualquier cookie de inicio de sesión existente, por lo que si su contraseña / cuenta se vio comprometida anteriormente, el atacante ya no tiene acceso.

En 2.0.0, agregamos la siguiente configuración para enganchar el OnValidateIdentitymétodo CookieMiddlewarepara mirar SecurityStampy rechazar las cookies cuando ha cambiado. También actualiza automáticamente los reclamos del usuario de la base de datos cada vez refreshIntervalque el sello no se modifica (lo que se ocupa de cosas como el cambio de roles, etc.)

app.UseCookieAuthentication(new CookieAuthenticationOptions {
    AuthenticationType = DefaultAuthenticationTypes.ApplicationCookie,
    LoginPath = new PathString("/Account/Login"),
    Provider = new CookieAuthenticationProvider {
        // Enables the application to validate the security stamp when the user logs in.
        // This is a security feature which is used when you change a password or add an external login to your account.  
        OnValidateIdentity = SecurityStampValidator.OnValidateIdentity<ApplicationUserManager, ApplicationUser>(
            validateInterval: TimeSpan.FromMinutes(30),
            regenerateIdentity: (manager, user) => user.GenerateUserIdentityAsync(manager))
    }
});

Si su aplicación quiere activar este comportamiento explícitamente, puede llamar a:

UserManager.UpdateSecurityStampAsync(userId);

El UseCookieAuthentication está en desuso por ahora. Logré configurarlo usando

services.Configure<SecurityStampValidatorOptions>(o => 
    o.ValidationInterval = TimeSpan.FromSeconds(10));

Movido de respuesta a respuesta por solicitud .

Observé que se requiere SecurityStamp para la verificación del token.

Para repositorio: establezca SecurityStamp en nulo en la base de datos Genere un token (funciona bien) Verifique el token (falla)