In the non-Core version of Identity, PasswordHasher is a non-generic type. Its HashPassword
method takes a single argument (the password to hash), and its VerifyHashedPassword
method takes only two (the password hash generated previously by HashPassword
, and the provided password to verify. This is great, because it means that I can use PasswordHasher
without going all-in and using the whole Identity framework.
In Microsoft.AspNetCore.Identity
, on the other hand, PasswordHasher<TUser>
is now a generic class, and the HashPassword
and VerifyHashedPassword
methods take a user
parameter in addition to the parameters that existed previously. This doesn't make much sense to me. Why does either hashing a password or verifying a hash require the user object? What's it used for?
Nothing. We can see in the source at https://github.com/dotnet/aspnetcore/blob/master/src/Identity/Extensions.Core/src/PasswordHasher.cs that neither the type parameter TUser
nor any of the user
parameters to the class's methods are ever used, at all.
I'd guess that the idea of having these parameters on the IPasswordHasher<TUser>
interface is to permit application-specific subclasses that do depend upon the user. For instance, I can imagine a situation where after a merger of two applications with different userbases, an application ends up having to deal with users whose passwords were hashed using different algorithms. Storing something like a PasswordFormat
field on the user model would then allow a custom IPasswordHasher<TUser>
to select which hashing algorithm to use based upon the user.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With