undefined | Better HN

0 pointsnkmnz3d ago0 comments

For me, the real issue of switching auth providers hasn’t been touched: do thy all use the same hashing functions or how did they move the password hash column across providers? Running them in parallel and rehashing on first login?

0 comments

anotherevan2d ago

If the provider is worth its salt¹ it will prefix the stored password with the hash that was used. That way it can update the hash when the user next logs in if it is out of date.

E.g.: {argon2}…

¹ See what I did there?

nkmnzOP2d ago

I see what you did there, but I assume you mean "prefix the stored hash with the algorithm that was used", right?

I still don't know how this would help with a migration, though. They would still need to run both auth systems in parallel until every single user has logged in again - or force everyone to create a new password. Right?

anotherevan2d ago

Assuming you get get access to the hashed passwords the other party used as part of the migration data, and you know what hash was used for them, then there's nothing to stop you using them yourself.

But in reality, I doubt they would release either of those things.

j / k navigate · click thread line to collapse

0 comments

anotherevan2d ago

If the provider is worth its salt¹ it will prefix the stored password with the hash that was used. That way it can update the hash when the user next logs in if it is out of date.

E.g.: {argon2}…

¹ See what I did there?

nkmnzOP2d ago

I see what you did there, but I assume you mean "prefix the stored hash with the algorithm that was used", right?

anotherevan2d ago

Assuming you get get access to the hashed passwords the other party used as part of the migration data, and you know what hash was used for them, then there's nothing to stop you using them yourself.

But in reality, I doubt they would release either of those things.

j / k navigate · click thread line to collapse