0

I have two different applications that are both running on aspnetcore. In application A I want to generate a new password, hash it, and store it in the database of application B, so a user can use this password to log into application B.

        private static string HashPassword(string password)
        {
            var hasher = new PasswordHasher<MockUser>(new OptionsWrapper<PasswordHasherOptions>(new PasswordHasherOptions{CompatibilityMode = PasswordHasherCompatibilityMode.IdentityV3}));
            var user = new MockUser();
            var hashedPw = hasher.HashPassword(user, password);
            return hashedPw;
        }

        private class MockUser : IdentityUser
        {
            
        }

If I subsequently store this password in application B, I can however not log in with the set password in application B. Application B uses the aspnetcore UserManager to manage logins. UserManager also uses PasswordHasher.HashPassword to set a password on users, and the user object that is passed does not affect the resulting hash, so I would expect it to work, however it does not.

Can anyone point me in the correct direction as to why hashing the password in application A does not result in a hash that allows me to log in at application B? I already tried both V3 and V2 options for the passwordhasher.

Pritom Sarkar
  • 2,154
  • 3
  • 11
  • 26
LordofTurtles
  • 65
  • 1
  • 8
  • Have you verified the salt length and iteration count are the same? Checkout VerifyHashedPasswordV3() in https://github.com/dotnet/aspnetcore/blob/70c05f178a33e018ed6c29295f0df190ad44b7e5/src/Identity/Extensions.Core/src/PasswordHasher.cs – Lee Reitz Nov 04 '21 at 15:05
  • The salt length is randomly generated by the passwordhasher, and stored in the hash, so it should be able to be used as well by the password hasher in application B as I understand it. The salt should not be handled on my end if I'm not mistaken – LordofTurtles Nov 04 '21 at 15:14
  • You are correct about salt, apologize for the confusion. The Iteration count and RandomNumberGenerator can be set in PasswordHasherOptions and would cause the verify method to fail if not the same. – Lee Reitz Nov 04 '21 at 15:37
  • The iteration count defaults to 10000, so should be the same across implementations. The rng is as far as I see only used to generate the salt, which is stored in the hash. If the rng instance differing would result in different hashes, would your passwords not stop working every time you redeploy an instance of the application? – LordofTurtles Nov 04 '21 at 15:49
  • 1
    As long as the hashers are configured the same, it will work across instances. Something must be different between the two applications. – Lee Reitz Nov 04 '21 at 15:58
  • Does [ASP.NET Identity's default Password Hasher - How does it work and is it secure?](https://stackoverflow.com/questions/20621950/asp-net-identitys-default-password-hasher-how-does-it-work-and-is-it-secure) and [Safely migrating passwords in ASP.NET Core Identity with a custom PasswordHasher](https://andrewlock.net/safely-migrating-passwords-in-asp-net-core-identity-with-a-custom-passwordhasher/) useful to u ? – Jason Pan Nov 05 '21 at 06:04

0 Answers0