Fred
Fred

Reputation: 4076

PasswordHasher<TUser> does nothing with TUser, why is that generic parameter there?

Here's the source for the password hasher. https://github.com/dotnet/AspNetCore/blob/master/src/Identity/Extensions.Core/src/PasswordHasher.cs

You can clearly see that the generic type TUser is only used in 2 public methods and in those methods the parameter itself is never used.

Why was this class genericized like this?

Upvotes: 3

Views: 468

Answers (2)

user23261339
user23261339

Reputation: 33

from Github [dotnet/aspnetcore] repo Why ASP.NET Core Identity PasswordHasher is taking TUser as generic argument.

GrabYourPitchforks:

It allows you to use information about the target user as part of the password hashing algorithm. Some applications use this as an extra layer of defense if they're particularly concerned about the consequences of their membership database being leaked. For example, some applications might opt to compute HMAC(hKey, user_identifier), where hKey is stored within an HSM, then combine the resulting digest with the per-user salt as part of the PBKDF routine. This algorithm would prevent somebody who downloads a copy of the membership database from mounting an offline attack.

Using per-user data in this fashion as part of the KDF isn't a very common scenario.

TanvirArjel:

@GrabYourPitchforks You are saying that if I override the HashPassword method and write my own implementation then I can use HMAC(hKey, user_identifier) for more security, am I correct? But in the default implementation, there is no usage of Tuser, Did I get things right?

GrabYourPitchforks:

@TanvirArjel the "more security" would largely come down to how hKey is stored - preferably within an HSM and marked non-exportable - but yes, that's the gist.

Upvotes: 1

Noah Stahl
Noah Stahl

Reputation: 7623

Interesting question. It seems likely there for extensibility purposes. A good comment from this article:

It is useful for cases when you implement your own IPasswordHasher. For example you may need to verify the password and you need the salt for the user if you salted your users password in your custom hasher. If the user wasn't provided you would need to get the user via a second trip to your user store if they only gave you the user email or id so could be able to hash passed in password against the sale for comparison.

Upvotes: 1

Related Questions