Breaking changes in identity hashing algorythms check

[piskov]

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

In .NET 7 @adityamandaleeka introduced breaking changes.

PasswordHasherCompatibilityMode.IdentityV3 logic was modified: algo changed to HMACSHA512 from HMACSHA256, iterations count changed to 100k from 10k, etc.

We recently upgraded from .net 6 to .net 9 and some of our legacy systems (still under .net framework, not .net core) now fail to login after they login in .net core app under the same account.

If I understand correctly, this is due to the introduced mandatory rehashing of v3 (old) to v3 (new) password on login. Which completely broke auth logic for .net framework (not .net core) clients as they under v3 compatibility expect previous values.

Please fix this because people still have great deal of legacy .NET Framework code.

From what I understand (most likely incorrect) this should never happened and instead of changes of v3 logic, PasswordHasherCompatibilityMode.IdentityV4 should have been introduced. Because — duh :) — that was the purpose of different compatibility modes in the first place.

Expected Behavior

Log in under .net 7+ and IdentityV3 compatibility shouldn’t rehash passwords from sha256 and 10k to sha512 and 100k iterations. For that new compatibility level v4 should be introduced.

Steps To Reproduce

No response

Exceptions (if any)

No response

.NET Version

.net7+

Anything else?

No response

[MackinnonBuck]

Thanks for reaching out, @piskov.

Short of a custom password hasher implementation in the .NET Framework app, we probably should have introduced an IdentityV4 here.

[adityamandaleeka]

Introducing V4 was considered and deemed unnecessary at the time (#37032 (comment)) cc: @GrabYourPitchforks

Did we just miss the NetFX compat angle?

[piskov]

As a workaround in .net core 7+ I’ve used custom PasswordHasher with simple logic to disable rehashing

 var result = base.VerifyHashedPassword(user, hashedPassword, providedPassword);
        return result switch
        {
            PasswordVerificationResult.SuccessRehashNeeded => PasswordVerificationResult.Success,
            _ => result,
        };

The issue is any already rehashed password (before the fix like the above) are completely broken and needed to be reset under previous logic (ie from app with .net 6 or .net framework 4). I just copied old hashes from the DB backup, but anyone else would be royally screwed.

[piskov]

Just for the sake of complete set of details:

• we have .net apps since 2010;
• first we had asp membership;
• then at some point in time we’ve migrated to asp identity using something like this;
• now we have .net core and some .net framework apps that still await the upgrade;
• in .net framework apps we have some custom implementations of AppUserManager, IdentityCoreCompat and UniversalPasswordHasher, with the latter supporting all three versions of password hashes:

        /* =======================
         * HASHED PASSWORD FORMATS
         * =======================
         *
         * Version 1:
         * SHA-1 (legacy, from Membership)
         * Format: password + '|' + 1 + '|' + salt
         * Implementation taken from: https://travis.io/blog/2015/03/24/migrate-from-aspnet-membership-to-aspnet-identity/
         *
         * Version 2:
         * PBKDF2 with HMAC-SHA1, 128-bit salt, 256-bit subkey, 1000 iterations.
         * (See also: SDL crypto guidelines v5.1, Part III)
         * Format: { 0x00, salt, subkey }
         * Implementation is copied as-is from the original PasswordHasher from Identity.
         *
         * Version 3:
         * PBKDF2 with HMAC-SHA256, 128-bit salt, 256-bit subkey, 10000 iterations.
         * Format: { 0x01, prf (UInt32), iter count (UInt32), salt length (UInt32), salt, subkey }
         * (All UInt32s are stored big-endian.)
         * Implementation is based on Identity.Core's code, rewritten to use Rfc2898DeriveBytes.
         */

Obviously, this code depended upon v3 being SHA256 with 10k iterations, which changed in .net 7.

I guess anyone with codebase of 15+ years (and who started with own asp accounts db from membership era) would have something like this. It’s probably a rare case, sure, but should not be uncommon in the enterprise sector.

Like I’ve said, we catheterized this by disabling rehashing under .net core login (until we migrate to .net core entirely) = it’s easier than to update our own UniversalPasswordHasher for legacy .net to support logic changed in .net 7