In the course of migrating a user database with a 2000s-era hand-rolled SHA1 hash template, I found there are fixed characters appended to every password/salt combination before hashing. If it wasn’t for the final two characters I’d have the API up and running and the user database already migrated.
sha1("--[salt]--[password]--")
(3 sets of two dashes)
I’ve followed the user import guidance here and here. I figure I could set the Okta salt to “–[my_old_salt]–” and specify saltOrder:PREFIX. But those final two dashes…
Is there a way to specify a custom template via the API (more flexible than pre/post-fix)? Could someone at Okta hard-code a couple dashes for me?
What values do you have? sha1() values or sha1() value, and salt, and password value?
Honestly, I would try cracking the passwords and see what success rate you get…then you could just create your own bcrypt() values and use the API to send the hash that way.
Very interesting. Hadn’t thought of that, basically change the Okta-side login.
Since we’re keeping the old site up for a while and I have access to the code I figured I’d do the reverse and create an Okta user (with their plaintext pw) every time someone logs into the old site. It won’t catch everyone right away like this idea would. At least their password will be stored in a modern way. Again, thanks!
It lets you create users in a special way and then the first time they authenticate, Okta will call out via a hook to some code that can validate the password. If everything checks out, Okta will migrate the password to a native login.