What is the purpose of Concurrencystamp and Securitystamp in ASP.NET Identity?

Question

The summary of both properties in the entity IdentityUser are in English:

Concurrencystamp: A Random value that must change Whenever a user is persisted to the store.

Translating would be something more or less thus:

A random value that should change whenever a user is persistent in the repository.

Securitystamp: A Random value that must change Whenever a users credentials change (password changed, login Removed).

Translating would be something more or less thus:

A random value that should change whenever there are changes in user credentials (Password changed, login removed).

I’m using Dapper instead of EF with Identity and Concurrencystamp never updates, so I thought it would be best to understand their purpose.

The Concurrencystamp I was very confused, and already the summary of Securitystamp managed to describe well. However I was super confused when I came across this answer in Soen.

And what I believed to be the function of Securitystamp apparently it is the function of Concurrencystamp.

• What are the purposes of these properties/table columns?
• I need to do something so that, for example, the Concurrencystamp perform your function correctly with Dapper? It seemed necessary after seeing this response using the EF.

Answer 1

Concurrencystamp represents the current status of the data in the repository and this is necessary to avoid competition problems. Example:

• An admin opens a user’s registration to edit their email address
• Another admin also opens the same user registration for the same thing
• The first admin updates the email and saves
• When the second admin saves, the Concurrecystamp will be different (because the dice he had loaded were already changed) and so casting an exception.

Securitystamp does the same thing but with the information related to the user’s credentials. If it depresses or changes the password Securitystamp changes, invalidating old cookies and other possible security problems.

About Dapper, apparently you don’t need to do anything. In the answer you mentioned, it just shows the implementation of IdentityDbContext to "prove" the above explanation.