Migrating Password Hash - UTF-16

I would like to create users with an imported password hash. Currently I have password hashes which were created from the UTF-16 (little endian) encoding of the password:

SHA-1(salt + [UTF-16 encoding of password])

From what I understand, Okta’s APIs use UTF-8 character sets, so it’s likely the hash Okta creates from the user-provided password would not match the database hash.

Is it possible to migrate these passwords to Okta using the password hash import?

I attempted to provide UTF-16-‘like’ data in the JSON for /api/v1/authn, but Okta rejects this (example below)

{
“username”: “sha1-2”,
“password”: “\u0074\u0000\u0065\u0000\u0073\u0000\u0074\u0000”
}

According to this doc,
Okta accepts base64-encoded hash of the password (and salt, if used).

1 Like

Hi there,

Yes, that is the API I want to use to create the user. However, the challenge is that the hash of the password is dependent on the byte-wise representation of the password, which changes depending on the encoding:

The bytes of the password ‘test’ in UTF-16LE: 74 00 65 00 73 00 74 00
SHA-1 hash: qUqP5cyxm6YcTAhz05Hph5gvu9M=

The bytes of the password ‘test’ in UTF-8: 74 65 73 74
SHA-1 hash: h/jtkVcSX/xNqeBqe4ARrYClP+E=

So the encoding with which Okta interprets a user supplied password impacts whether the password will be accepted. If I import the hash qUqP5cyxm6YcTAhz05Hph5gvu9M= from my legacy system, but Okta generates h/jtkVcSX/xNqeBqe4ARrYClP+E= when the user tries to log in, they won’t be able to sign in.

Did you ever find a solution to this? We are running into the same issue currently. We’ve tested that by creating a user and updating their credentials with a UTF-8 encoded and hashed password the user can log in as expected via Okta but all of our passwords that are encoded with UTF-16 fail to authenticate in Okta.

Hi @cdunlap and @python,

I get what you’re saying. You are correct that Okta’s APIs use UTF-8 so what you can do is use a Password Import Inline Hook. Here are the docs on this:
https://developer.okta.com/docs/reference/password-hook/

Thanks, @erin.p . This is what we’ve been looking into since running into this hurdle. The password import hook will work for us I think. Unfortunately, going that route still leaves us in a bit of a hard spot as the password import hook will only work for users who log in after implementing that. For any users that have been inactive for a period, we essentially have 2 options. Either continue to support our legacy authentication system until all users have logged in to Okta (probably never going to happen if we’re being honest) or once we shut down our legacy auth system, any users who have not signed in since moving to Okta will be required to go through a reset password flow.

That sounds right, if you don’t want to keep your legacy system active then yes, they will have to go through the password reset flow