Thanks for your very useful post!
The code in wordpress is unfortunately broken, the function create_12c_password_hash does not compile.
Looking at the PDF I see that the external loop in create_12c_password_hash is useless because v_octet_blocks is constant and is always 1.
Also, the case statement in the inner loop can be avoided by initializing v_f_xor_sum to utl_raw.cast_from_binary_integer(0);
Thank you for reading and the feedback. WordPress “formatted” my code, causing errors in the html rendering. I’ve fixed the errors and reposted. Thank you again.
You are correct that the loop isn’t necessary. However I chose to leave it in place so the code would still follow the PBKDF2 algorithm as documented in the RFC. I simplified it by declaring constants for values that should be parameters in a general-purpose implementation; but the code flow should be essentially the same as that described in the RFC.
I have updated the code with the loop counter defined as a constant though, since it’s not variable within this implementation and removed the case by seeding the 1st set of values directly.
Thanks again!
Thank you so much Sean. Your work is very useful.
Hi Sean.
What I’ve got from your article, if I execute the next line:
select create_12c_password_hash(‘testpwd’,’58645C9EA1D1E33C33CB9454D0468BF9′) from dual;
I should obtain the same hash that is saved on USER$.SPARE4 given that the password of my user is “testpwd” and the last 32 characters (the salt) are ‘58645C9EA1D1E33C33CB9454D0468BF9’, but the hash I’m getting is different. It seems there’s something I’m doing wrong. Could you help me please?
By the way, I really appreciate your work; it’s helping me a lot.
Thanks for your very useful post!
The code in wordpress is unfortunately broken, the function create_12c_password_hash does not compile.
Looking at the PDF I see that the external loop in create_12c_password_hash is useless because v_octet_blocks is constant and is always 1.
Also, the case statement in the inner loop can be avoided by initializing v_f_xor_sum to utl_raw.cast_from_binary_integer(0);
Thank you for reading and the feedback. WordPress “formatted” my code, causing errors in the html rendering. I’ve fixed the errors and reposted. Thank you again.
You are correct that the loop isn’t necessary. However I chose to leave it in place so the code would still follow the PBKDF2 algorithm as documented in the RFC. I simplified it by declaring constants for values that should be parameters in a general-purpose implementation; but the code flow should be essentially the same as that described in the RFC.
I have updated the code with the loop counter defined as a constant though, since it’s not variable within this implementation and removed the case by seeding the 1st set of values directly.
Thanks again!
Thank you so much Sean. Your work is very useful.
Hi Sean.
What I’ve got from your article, if I execute the next line:
select create_12c_password_hash(‘testpwd’,’58645C9EA1D1E33C33CB9454D0468BF9′) from dual;
I should obtain the same hash that is saved on USER$.SPARE4 given that the password of my user is “testpwd” and the last 32 characters (the salt) are ‘58645C9EA1D1E33C33CB9454D0468BF9’, but the hash I’m getting is different. It seems there’s something I’m doing wrong. Could you help me please?
By the way, I really appreciate your work; it’s helping me a lot.
Thanks!