In Firebase, the password hash is stored in passwordHash and is hashed using SCRYPT with specific parameters. In Supabase, the password is stored in encrypted_password and is hashed using bcrypt. As a result, when migrating authenticated users, an error occurs due to the different password hashing algorithms.
Bug report
The difference between the newly created Supabase user and the migrated Firebase user is primarily in the password handling. Here’s a breakdown of the issues and potential reasons for the "invalid_grant" error:
Password Storage and Hashing Differences Supabase User ([email protected]):
The password is stored in encrypted_password and is hashed using bcrypt ($2a$10$d31Fd//DLU.28P2H3.ywpOqkfrBODA74IlmuNtU3LbJPm/1hhYGhy). This indicates that the password is correctly hashed and stored by Supabase's default bcrypt implementation.
Migrated Firebase User ([email protected]):
The password hash is stored in passwordHash and uses SCRYPT with specific parameters. This user’s encrypted_password is empty, and the passwordHash field contains the SCRYPT-based hash. hash_parameters include details like rounds, mem_cost, algorithm, and base64 encoding, which indicates SCRYPT was used for hashing.
Due to this issue, we are unable to authenticate Firebase users in Supabase. As discussed, you mentioned that this is a bug and that you will soon update the password hashing in Supabase.
Thanks Deepak. For interested contributors a reference PR for argon2id is here: https://github.com/supabase/auth/pull/1597
Update: On further inspection, I'm not sure that a direct mirror of the above PR will work as unlike argon2, not all hash metadata is contained within the hash. Metadata external to the hash is needed
We decided to establish a default convention, similar to what's used with argon2id
Hello J0,
Thanks for your reply.
I'm not entirely sure what you mean by argon2id, but the basic concern is that if Supabase provides the capability to directly migrate authenticated users from Firebase into Supabase, it should work seamlessly without compatibility issues related to different hashing algorithms.
However, if the argon2id requirement is a core part of Supabase's authentication security, it would be helpful to understand how this affects the migration process. Is there a workaround or recommended approach for handling these differences in hash formats?
Also, based on your decision regarding the use of argon2id, can you confirm whether the previous query I provided will work as expected, or if any adjustments are needed to ensure smooth migration?
Looking forward to your guidance.
Best regards,
Hey,
Thanks for the follow up - we had a further discussion and we decided to define a format for scrypt users - if passwords are converted into that format you should be able to log in seemlessly. We're working on the PR now, and will get back to you soon - we ask for your patience in the meantime.
Sure J0, I'll wait for your response. Thanks.