Here is what I’ve been trying.
I take our hash (bo4ditnmyAyz1E49eZ88pr5f7G6wgQNTzp/SVihRRvN3KwbqeNqwQZS8+R0UoLwd)
I decode it from base64 to a byte array
I split the first 16 bytes off the front and base 64 encode them. I use this for the salt
The remaining bytes I base64 encode and use as the value
Here is the body of the POST to {{url}}/api/v1/users?activate=false:
I tried a few other things too. I tried with the whole hash above as the value. I tried giving it a workFactor of 100000, though I suspect that does nothing for SHA-256. I tried logging in before and after activating the user through the okta ui.
Am I correct that the 100000 iterations is causing us the problem? Is there some way I need to tell Okta about the 100000 iterations? Are the iterations supported?
I just took a look at this, but unfortunately, our import API won’t support your type of hash at the moment I just spoke with the PM for the endpoint and chatted about potentially getting this supported. Hopefully we can get something added to the product queue in the near future!
As you might be able to tell, this is a relatively new endpoint/feature for us. We designed it to support bcrypt hashes (which are more and more common), but haven’t yet optimized support for other types of hashes (including iteration count and NOT work factor).
The only real solution for you at the moment is sorta tricky:
Have users authenticate against your web server
Grab their plain-text password and try to authenticate against Okta
If the authentication against Okta fails (no user account), try to authenticate the user against your local database with your current hashing strategy
If the authentication works against your local db, you can then create the account with the plain-text password in Okta, at which point Okta will hash the plain-text password with our own stuff, thereby “upgrading” the hash without forcing a password reset
I realize this is super annoying, I’m sorry =/
The other option, of course, would be to reset your user passwords after importing them into Okta, but that obviously wouldn’t be ideal.
I’ll update this thread if I hear something back. Hang in there!
As I continued to dig into this problem yesterday, I also found a problem in the way I was sending the salt. I was base 64 encoding it, but it appears that the API doesn’t expect the salt to be encoded. We use random bytes for the salt which may include nonprinting characters that cannot be sent in the json body of a POST without first encoding it.