Use the framework implementation of PBKDF2/RFC2898

[omajid]

This is a follow up from aspnet/DataProtection#272, #2508 and dotnet/runtime#24897.

ASP.NET has its own implementation of RFC2898 because it needs top-of-the-line performance for password hashing in order to have acceptable latency for login scenarios. If we bring these performance improvements to the framework's implementation of these APIs, ASP.NET can remove its own implementation and rely on the standard classes.

This was recently fixed via dotnet/runtime#48107.

This bug/feature-request is to track that ASP.NET Core picks up and uses that API and removes its duplicate implementation.

cc @bartonjs @blowdart @GrabYourPitchforks @tmds @Tornhoof @vcsjones

[blowdart]

@HaoK

[ghost]

Thanks for contacting us.
We're moving this issue to the Next sprint planning milestone for future evaluation / consideration. We will evaluate the request when we are planning the work for the next milestone. To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

[HaoK]

Cool, I'll combine this into the existing span issue

[omajid]

Hi @HaoK ! Are there any plans to remove the managed implementation and/or Win7Pbkdf2Provider/Win8Pbkdf2Provider implementations? Will those be kept around for compatibility?

[HaoK]

Unfortunately we still have to support netstandard and net461, we can't use the new one shot pbdkdf2 in those target frameworks right?

[HaoK]

Is the new API faster than the Win8/Win7 implementations as well? We can switch the code to always use the NetCore provider when available and only use the Win8/7/Managed implementations on netstandard/net461

[vcsjones]

we can't use the new one shot pbdkdf2 in those target frameworks right?

Correct. It is .NET 6.

Is the new API faster than the Win8/Win7 implementations as well?

It should be "as fast or better". It borrows many ideas from the DataProtection implementation for Windows, and has a slight allocation improvement for Windows 10+.

On MacOS it uses CommonCrypto from the underlying OS, and for Linux it uses openssl.

[HaoK]

Cool, so sounds like we should just switch to always using this on netcoreapp, and keeping the old branching providers only for non netcoreapp, I'll open a PR tomorrow, thanks for pointing this out

[omajid]

Thanks!