Stuck with SHA1 on .NET Standard 2.0

Question

I am making an upgrade from .NET Framework to hopefully .NET. The thing is that we have a big solution with more than a 100 projects. The idea is that this can go into stages. We could upgrade to .NET Standard 2.0 (highest we can go), and then upgrade in stages to .NET (Some may never go to .NET, or be separated in other solutions).

The problem I am having is mentioned in the issue: Cannot specify 4 arguments (hash algorithm name) for Rfc2898DeriveBytes.

To be more specific, in our current .NET Framework solution we are using a higher hashing algorithm, but .NET Standard is forcing SHA1. See Rfc2898DeriveBytes Class.

NIST strongly advises against using SHA1. See NIST Retires SHA-1 Cryptographic Algorithm. I wouldn't call it a zero-day vulnerability since NIST plans on phasing out by Dec. 31, 2030.

Using 3rd party libraries for something this crucial is not an option.

We have zero-knowledge policy on our passwords. Also with .NET Standard 2.0, the application couldn't dynamically encrypt and compare hashes made with higher hashing algorithms. This makes the application unusable.

One option would be to create a new .NET project that would simply supply a result to a .NET Standard project.

Am I missing something? Any ideas?

Answer 1

SHA-1 is indeed vulnerable against attacks. However, it is mainly/only broken when it comes to collision resistance. In principle it is possible to make PBKDF2 an exception as it doesn't rely on the collision resistance property. This would be problematic if you already have PBKDF2 hashes or derived keys that do use a different hash as they would not be compatible. You'd preferably also limit to 160 bits of output with SHA-1 due to the way that PBKDF2 has been (badly) designed.

Another option is to use an alternate implementation that does provide choice of hashes for PBKDF2. The Mono framework probably has a good implementation that has an identical interface to the one you're using, although it depends on the framework how many classes need to be dragged in with their Rfc2898DeriveBytes implementation (dependencies). Disadvantage are the identical namespace of their implementation and missing updates. Beware that software implementations of PBKFD2 may be significantly slower, which may give an advantage to possible adversaries.

Finally this may be an opportunity to get rid of PBKDF2 in favor of newer / better algorithms such as a secure version of Argon2. That's not NIST approved, but PBKDF2 is simply not best of class anymore. This is a risky move to make when you're upgrading to a new framework though.