Unable to import PBKDF2 passwords

[callumcodes]

Hello,

I'm experimenting with Ory Kratos, using the quick start and I'm trying to import pbkdf2 passwords (which is what my existing users are stored in) but I can't get it to work.

I'm running locally using the command from the guide:
docker-compose -f quickstart.yml -f quickstart-standalone.yml up --build --force-recreate

I've successfully imported a clear text password and an md5 password following the documentation but can't get pbkdf2 to work.

Here is my post request to http://localhost:4434/admin/identities:

{
  "schema_id": "default",
  "traits": {
    "email": "potato@example.com"
  },
  "credentials": {
    "password": {
      "config": {
        "hashed_password": "$pbkdf2-sha1$i=3000,l=32$W9qjjsiqt3DSXwlhMB2Dvg==$Rn423poYrpat2x7N6PlUFFgqfP6JqAFjPpMISu6i1xg="
      }
    }
  }
}

The password is potato.

When I try to login within the credentials, I'm just receiving:

The provided credentials are invalid, check for spelling mistakes in your password or username, email address, or phone number.

Do you have any pointers of what I doing wrong? My input seems to match the spec as per the import identities doc

Thank you in advance!

[callumcodes]

Update:

I got this working in the end.
For some reason, as exemplified by the E2E test, you need to remove the = padding from the base64 encoded hash and salt. This should probably be in the documentation for importing hashed passwords as this pretty unintuitive.

My working request became:

{
  "schema_id": "default",
  "traits": {
    "email": "potato@example.com"
  },
  "credentials": {
    "password": {
      "config": {
        "hashed_password": "$pbkdf2-sha1$i=3000,l=32$W9qjjsiqt3DSXwlhMB2Dvg$Rn423poYrpat2x7N6PlUFFgqfP6JqAFjPpMISu6i1xg"
      }
    }
  }
}

Also I noticed a bug in the E2E test as well:

$pbkdf2-sha256$i=1000,l=128$e8/arsEf4cvQihdNgqj0Nw$5xQQKNTyeTHx2Ld5/JDE7A

The derived length in octets is listed as 128, when the length is actually 16 (128 bits).
This is not currently failing because in the pbkdf2 decoded logic, it completely ignores the l parameter by setting the key length to that of the decoded base64 hash.

[callumcodes]

Which part? The fact the l= parameter is completely ignored of that you have to break the base64 encoding of the hash+salt to make them import properly? I assumed at least one of these was a bug.

[aeneasr]

I guess both (parameter l is not used, base64 encoding expects strict encoding aka no padding)

[reidrac]

I guess both (parameter l is not used, base64 encoding expects strict encoding aka no padding)

Would you consider perhaps comparing the value of l with the size of the hash (which is the value used currently) and reporting an error if they don't match?

Seems like documenting the format, including a parameter, and then documenting that the parameter is ignored is putting the effort in the wrong place.

[aeneasr]

I meant removing the parameter from the docs, as it's ineffective. I'm not sure why it's there to be honest.

[reidrac]

Edit: doesn't look like it!

The code scans for it:

kratos/hash/hash_comparator.go

Line 433 in f441f41

_, err = fmt.Sscanf(parts[2], "i=%d,l=%d", &p.Iterations, &p.KeyLength)

Then it is overridden later on using the size of the hash instead. That's why I suggested that we compare them to make that l parameter have an use.

If we remove it from the docs, the format of the string will be wrong.