User Authentication

  • 3/26/2020 11:36:11 PM

  • About 2 minutes to read

Plato leverages the identity services & best practices provided by .NET Core for user authentication and account recovery.


Passwords within Plato are hashed. A hash is a one way function, so given the password you can work out the hash, but given the hash you can't get the original password back. For security reasons, the characteristics of the hash function are important; in particular, the hash function should be relatively costly to compute, so that if your database of password hashes were to be compromised, it would take a long time to crack them.

Plato uses the default IPasswordHasher<TUser> implementation provided by .NET Core to hash user passwords before they are persisted within the Plato database.

The default implementation in the Identity framework is the PasswordHasher<TUser> class (source code). This class is designed to work with two different hashing formats:

  • ASP.NET Identity Version 2: PBKDF2 with HMAC-SHA1, 128-bit salt, 256-bit subkey, 1000 iterations
  • ASP.NET Core Identity Version 3: PBKDF2 with HMAC-SHA256, 128-bit salt, 256-bit subkey, 10000 iterations

The PasswordHasher<TUser> class can hash passwords in both of these formats, as well as verify passwords stored in either one.

When a user attempts to login again the users hash is computed again via the IPasswordHasher<TUser> implementation and compared against the hash stored within the database. If the username and hash match the stored details this would be considered a successful login.


Plato uses cookie based authentication provided by the ASP.NET Core Identity services to persist user authentication. As the name suggests by default user authentication within Plato is persisted on the client side via an authentication cookie.

Plato uses regular .NET Core objects such as ClaimsPrincipal and ClaimsIdentity to represent a user and serialize user information into the client side authentication cookie.

To create this authentication cookie Plato uses the default SignInManager implementation provided by ASP.NET Core Identity. The SignInAsync method exposed by the SignInManager creates an encrypted cookie and adds it to the current response.

The client side authentication cookie for Plato is typically named plato_{sitename} where {sitename} is the name of your site provided during the web based set-up process.

Security Stamp

The security stamp can be used to invalidate logins or automatically logout users.

When a user successfully authenticates within Plato a unique security stamp is generated and stored within the plato_Users.SecurityStamp database column. This same security stamp is also stored within a cooke on the clients device.

If the stored security stamp changes for the user the client side cookie will be automatically invalidated for the user meaning the user will be automatically logged out. This is used within Plato when you ban users or flag users as spam to ensure those users are automatically logged out.

Can we improve this doc? Login or register to tell us how
Your Feedback
In this doc