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. #1750
Comments
|
Thanks Deepak. For interested contributors a reference PR for argon2id is here: #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 |
|
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. |
## What kind of change does this PR introduce? Fix #1750. Firebase uses a [modified version of scrypt](https://github.com/firebase/scrypt) We add support for Firebase Scrypt hashes so that developers can move over from Firebase (or similar) without the obligation to force a password reset for all users. As there is no pre-defined convention for Firebase scrypt hashes, we establish the following: ``` $fbscrypt$v=1,n=<N>,r=<r>,p=<p>[,ss=<salt_separator>][,sk=<signer_key>]$<salt>$<hash> ``` ``` $fbscrypt: Firebase scrypt Identifier $v: version identifier. Intended to allow for flexibility in parameters used. $n: N is the CPU/memory cost parameter. $r: block size $p: parallelization $ss: salt seperator, optional, only if using firebase, base64-encoded string used to separate the salt from other parameters. $sk: signer key, a base64-encoded string used as an additional input to the hash function. $<salt>: base64 encoded salt $<hash>: base64 encoded output ```` Developers can extract their [hash parameters from the firebase console](https://firebaseopensource.com/projects/firebase/scrypt/) For testing and debugging, clone this [utility](https://github.com/firebase/scrypt/#finding-the-password-hash-parameters) and follow the instructions in `BUILDING`. On MacOS please add the following flags when attempting to build so as to guard against error: `AES_FUNCTION` missing ``` export CFLAGS="-I$(brew --prefix openssl)/include" export LDFLAGS="-L$(brew --prefix openssl)/lib -L/usr/local/opt/openssl/lib" ``` [More details about export from CLI](https://firebase.google.com/docs/cli/auth)
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 (newsupabase1@yopmail.com):
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 (newusersexperienced@yopmail.com):
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.
The text was updated successfully, but these errors were encountered: