The hashing algorithm that was used to generate the password digest. The algorithms we support at the moment are bcrypt, md5, pbkdf2_sha256, pbkdf2_sha256_django, scrypt_firebase and 2 argon2 variants, argon2i and argon2id. Each of the above expects the incoming digest to be of a particular format. More specifically: bcrypt: The digest should be of the following form: $<algorithm version>$<cost>$<salt & hash>md5: The digest should follow the regular form e.g.: 5f4dcc3b5aa765d61d8327deb882cf99pbkdf2_sha256: This is the PBKDF2 algorithm using the SHA256 hashing function. The format should be as follows: pbkdf2_sha256$<iterations>$<salt>$<hash> Note: Both the salt and the hash are expected to be base64-encoded. pbkdf2_sha256_django: This is the Django-specific variant of PBKDF2 and the digest should have the following format (as exported from Django): pbkdf2_sha256$<iterations>$<salt>$<hash> Note: The salt is expected to be un-encoded, the hash is expected base64-encoded. pbkdf2_sha1: This is similar to pkbdf2_sha256_django, but with two differences: 1. uses sha1 instead of sha256 2. accepts the hash as a hex-encoded string The format is the following: pbkdf2_sha1$<iterations>$<salt>$<hash-as-hex-string>scrypt_firebase: The Firebase-specific variant of scrypt. The value is expected to have 6 segments separated by the $ character and include the following information: hash: The actual Base64 hash. This can be retrieved when exporting the user from Firebase. salt: The salt used to generate the above hash. Again, this is given when exporting the user. signer key: The base64 encoded signer key. salt separator: The base64 encoded salt separator. rounds: The number of rounds the algorithm needs to run. memory cost: The cost of the algorithm run The first 2 (hash and salt) are per user and can be retrieved when exporting the user from Firebase. The other 4 values (signer key, salt separator, rounds and memory cost) are project-wide settings and can be retrieved from the project’s password hash parameters. Once you have all these, you can combine it in the following format and send this as the digest in order for Clerk to accept it: <hash>$<salt>$<signer key>$<salt separator>$<rounds>$<memory cost>argon2i: Algorithms in the argon2 family generate digests that encode the following information: version (v): The argon version, version 19 is assumed memory (m): The memory used by the algorithm (in kibibytes) iterations (t): The number of iterations to perform parallelism (p): The number of threads to use Parts are demarcated by the $ character, with the first part identifying the algorithm variant. The middle part is a comma-separated list of the encoding options (memory, iterations, parallelism). The final part is the actual digest. $argon2i$v=19$m=4096,t=3,p=1$4t6CL3P7YiHBtwESXawI8Hm20zJj4cs7/4/G3c187e0$m7RQFczcKr5bIR0IIxbpO2P0tyrLjf3eUW3M3QSwnLcargon2id: See the previous algorithm for an explanation of the formatting. For the argon2id case, the value of the algorithm in the first part of the digest is argon2id: $argon2id$v=19$m=64,t=4,p=8$Z2liZXJyaXNo$iGXEpMBTDYQ8G/71tF0qGjxRHEmR3gpGULcE93zUJVU If you need support for any particular hashing algorithm, please let us know.