0

My company is in the middle of migrating their old application (perl) into their new application (oracle apex). We currently have all of our internal processes up and running on oracle apex, while all of our merchants still use the old application. I'm creating the merchant setup in apex (our support users set up merchant accounts for them), in which part of this setup I need to create the logins for the merchant to use. The problem is that our old application used the perl crypt function to hash our merchants passwords, so my custom hash in apex does not match the same digest thus not allowing the merchants to sign in. I'm wondering if I have the code to create the exact same salt as the old application, can oracle's DBMS_CRYPTO replicate the exact same hash as the perl crypt function? $cpw = crypt ($pw, $salt);

Update Sep 09 2022: To avoid a scheduled maintenance and having to import jars into the db, i'm looking into an alternative solution that involves taking the password hashing code out of the original application and re-creating it in it's own cgi file. Then using apex_web_service.make_rest_request to POST our user's password and have the script that contains the crypt() function handle hashing of the password.

LogicallyFunky
  • 61
  • 1
  • 9
  • 2
    The [Perl docs](https://perldoc.perl.org/functions/crypt) suggest it's the same as [C's crypt(3)](http://man.he.net/man3/crypt) which is "based on the Data Encryption Standard algorithm with variations", so [probably not](https://docs.oracle.com/en/database/oracle/oracle-database/19/arpls/DBMS_CRYPTO.html#GUID-CE3CF17D-E781-47CB-AEE7-19A9B2BCD3EC) - I think you'd need to recreate the algorithm as a PL/SQL function (or stored Java procedure perhaps - I ported the C code to Java once long ago, which was a bit of a pain as I recall...). – Alex Poole Sep 08 '22 at 13:59
  • The prefix of the hash values (or the lack of a prefix) give you an indication which hash algorithm has been used; see https://en.wikipedia.org/wiki/Crypt_(C)#Support_in_operating_systems – Erich Kitzmueller Sep 08 '22 at 14:39

1 Answers1

2

If you have Java enabled in the database then you may be able to (untested):

  1. Use the loadjava utility to import the apache.commons.codec library which contains the org.apache.commons.codec.digest.Crypt class.

  2. Create a PL/SQL function to wrap the Java method:

    CREATE OR REPLACE FUNCTION CRYPT(
  i_key  IN VARCHAR2,
  i_salt IN VARCHAR2
) RETURN VARCHAR2
AS LANGUAGE JAVA
NAME 'org.apache.commons.codec.digest.Crypt.crypt(java.lang.String, java.lang.String) return java.lang.String';
/

Then you can call that function and compare it to Perl.

MT0
  • 143,790
  • 11
  • 59
  • 117
  • When I tried to call my function I received this error: `Error report - ORA-29540: class org/apache/commons/codec/digest/Crypt does not exist ORA-06512: at "ANALYST.CRYPT", line 1 ORA-06512: at line 17 29540. 00000 - "class %s does not exist" *Cause: Java method execution failed to find a class with the indicated name. *Action: Correct the name or add the missing Java class.` – LogicallyFunky Sep 09 '22 at 12:33
  • @LogicallyFunky When I download the [binary](https://commons.apache.org/proper/commons-codec/download_codec.cgi) and extract the JAR file then that class does exist in it. Did you use the `loadjava` utility to load the JAR into the database? Did you load it into the correct schema? Did you check if there were any errors loading the archive? – MT0 Sep 09 '22 at 12:43
  • Talked to my dba, in order to enable java, it's requiring us to restart our ATP db. Will have to wait for an opportune time to do this, appreciate your insight and quick responses. – LogicallyFunky Sep 09 '22 at 19:05