Current system uses PHP 8.2 and password_hash which I believe uses bCrypt with a (mandatory) random salt and is something we build ourselves - we are moving to a new IDS system which is .Net and uses AspNetCoreIdentity which is using PBKDF2 with SHA512 and we generate a salt (we have very limited access to the codebase/database etc on the new system)
We want to be able to migrate users seamlessly between the two identity systems i.e. no one has to reset their passwords so the plan is to add into the current PHP system a hash generator which will take the clear password (at login/password change for example) and mimic the new ASPNet hash (using the same settings for iterations, algorithm, length etc) so the user table will then have 2 entries (updated every time the user logins/updates password etc) - one for the current PHP hash and one for .Net hash
Then we want to move the new .Net hashes over to the .Net system at an agreeable time in the hope that the user will still be login as we will have a .Net version of their password.
The thing I am struggling with is the salt - in both cases the salt is random. With that in mind, if I hash the password "password" 10 times (on either side) it will return me a different hash every time.
Is it even possible to do this? If I do the above and, assuming all password changes etc are managed, will the above concept work? Prior to using password_hash we used to store the salt in a separate column so how does this work when the salt is random?