#1
  1. No Profile Picture
    Registered User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Aug 2004
    Posts
    11
    Rep Power
    0

    Standard DES encrypt / hash for passwords stored in DB


    I'm working on a project right now to migrate some of our legacy programs from a combination of Oracle Forms and PHP to Oracle APEX. Basically our authentication works something like this...

    A central server distributes a hashed password file (similar to .htaccess). For these applications, that files is loaded into the DB. A PHP form allows the user to enter their UID/PW which is then checked against the hash contained within the DB and returns a pass/fail. The applications then handle everything else.

    The hashed password basically looks like 'zxGGvavFYvvhs' where the first to characters are the salt. Using the PHP crypt function, you can validate the matching hash...
    PHP Code:
    crypt('password''zx') == 'zxGGvavFYvvhs' 
    Is there a way that I can do this via PL/SQL using any of the provided Oracle procedures/functions or possibly a procedure written as a Java function? I've looked at dbms_crypto and dbms_obfuscation_toolkit and haven't been able to get either to generate a matching hash. I do not need the ability to decrypt a string, I just need to generate a matching hash.
  2. #2
  3. Contributing User
    Devshed Novice (500 - 999 posts)

    Join Date
    Sep 2006
    Posts
    857
    Rep Power
    388

    Cool


    Originally Posted by d3bruts1d
    I'm working on a project right now to . . .
    . . . Etc . . .
    The hashed password basically looks like 'zxGGvavFYvvhs' where the first to characters are the salt. Using the PHP crypt function, you can validate the matching hash...
    ... and haven't been able to get either to generate a matching hash. I do not need the ability to decrypt a string, I just need to generate a matching hash.
    OK, ok....
    Here, use mine:
    Code:
    CREATE OR REPLACE FUNCTION crypt 
        ( p_input_string VARCHAR2, p_key_bytes VARCHAR2 DEFAULT 'zx')
      RETURN VARCHAR2
    IS
      input_string    VARCHAR2 (4000);
      key_bytes       VARCHAR2 (8) := 'zx';
      num_key_bytes   NUMBER := 2;
      decrypted_raw   VARCHAR2 (4000);
      encrypted_raw   VARCHAR2 (4000);
      hash_length     NUMBER := 13;
      hash_return     VARCHAR2 (200);
    BEGIN
      input_string    := p_input_string;
      key_bytes       := p_key_bytes;
      num_key_bytes   := LENGTH ( key_bytes);
      decrypted_raw   := SUBSTR ( LPAD ( key_bytes, hash_length, key_bytes)||input_string, 1, 64);
      DBMS_RANDOM.seed ( decrypted_raw);
      encrypted_raw   := key_bytes || DBMS_RANDOM.string ( 'a', hash_length);
      RETURN encrypted_raw;
    END;
    /
    Last edited by LKBrwn_DBA; December 12th, 2013 at 03:53 PM.
  4. #3
  5. No Profile Picture
    Registered User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Aug 2004
    Posts
    11
    Rep Power
    0
    Thanks for the help. That gets me close, but not quite there. I have to match a hash that is being provided by a 3rd party. This code doesn't do that.

    The hash can contain alpha numeric characters, however looking at some of the hashes we have I noticed that many hashes also contain forward slashes and periods. Unfortunately, if you set DBMS_RANDOM.string opt=>'p' you get (almost always) unacceptable characters. Because of this, I don't think there is anyway to make DBMS_RANDOM work for this need.

    Apparently the PHP crypt() function is based on an old UNIX method, which naturally Oracle doesn't support in the crypto package.
  6. #4
  7. Contributing User
    Devshed Novice (500 - 999 posts)

    Join Date
    Sep 2006
    Posts
    857
    Rep Power
    388

    Cool


    Originally Posted by d3bruts1d
    Thanks for the help. That gets me close, but not quite there. I have to match a hash that is being provided by a 3rd party. This code doesn't do that.
    . . . E t c . . .
    You do not actually need to "match" that hash, just replace it with a new one!
  8. #5
  9. --
    Devshed Expert (3500 - 3999 posts)

    Join Date
    Jul 2012
    Posts
    3,959
    Rep Power
    1014
    What on earth does the function above have to do with crypt()? It's nothing but a (very poor) random number generator.



    @d3bruts1d:

    I strongly recommend keeping away from any home-made implementation. The hashes are actually important. If you fail to validate them correctly, you have a serious security problem.

    Also note that crypt() itself is totally outdated and offers no security. It may have been acceptable in the 70s and 80s, but hardware has evolved since. Any gamer PC can try out billions of possible passwords per second.

    If your company is serious about security, the crypt() stuff must be replaced with a real hash algorithm like bcrypt. Otherwise, you might as well store the plaintext passwords and write "Please don't hack us!" on top of the file.
    The 6 worst sins of security ē How to (properly) access a MySQL database with PHP

    Why canít I use certain words like "drop" as part of my Security Question answers?
    There are certain words used by hackers to try to gain access to systems and manipulate data; therefore, the following words are restricted: "select," "delete," "update," "insert," "drop" and "null".
  10. #6
  11. No Profile Picture
    Registered User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Aug 2004
    Posts
    11
    Rep Power
    0
    @Jacques1:

    Thanks. Our company uses a custom application to manage and distribute passwords. Right now, the password has sent to us is basically a .htaccess file (userw_hash) where the first 2 characters of the hash is the salt.

    This file basically comes to us, and we load it into a custom "users" table. So then when a user logs in we basically use PHP to generate a hash and then compare it to the value stored in the table for the user. Underneath is a single DB user that actually does everything within the system while the application itself has its own authorization system. We could have just as easily thrown the .htaccess file into the Apache/bin folder and relied on the Apache component of OHS/OAS to handle authentication. We chose to do the PHP route at the time since it was a bit easier to handle (~7k users) across all the different directories, virtual directories, and some other applications (Forms & Reports).

    It looks like our password management system has the ability to encrypt in different formats, I just looked at a 2nd system that is very similar (Oracle Forms with a Perl authentication handler) and the .htaccess file we receive on that system is something similar to this...

    user:$apr1$1w/.....$sjclahGjakdhFjebxjakX1

    whereas the current system I'm working on is...

    user:SYI/SZrNb4ymA

    If I could figure out what the first one is, I might be able to switch over to that encryption.
  12. #7
  13. --
    Devshed Expert (3500 - 3999 posts)

    Join Date
    Jul 2012
    Posts
    3,959
    Rep Power
    1014
    The first hash is a Apache-specific algorithm based on MD5. It might be slightly better, but it's still nowhere near state of the art.

    If the password system doesn't support modern algorithms like bcrypt, it needs to be updated. After that, it won't be a problem to calculate the hashes with PHP, Java or whatever. Those languages all have a bcrypt implementation.

    Comments on this post

    • d3bruts1d agrees
    The 6 worst sins of security ē How to (properly) access a MySQL database with PHP

    Why canít I use certain words like "drop" as part of my Security Question answers?
    There are certain words used by hackers to try to gain access to systems and manipulate data; therefore, the following words are restricted: "select," "delete," "update," "insert," "drop" and "null".
  14. #8
  15. No Profile Picture
    Registered User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Aug 2004
    Posts
    11
    Rep Power
    0
    I found out that our password management system is basically able to provide us anything that is available via OpenSSL. Why they are only currently doing the Apache APR1-MD5 and crypt(1) formats is beyond me.

    The good news is, if I can figure out what lines up in OpenSSL to a method that can be reproduced via DBMS_CRYPTO I should be good. The bad news is, I have to figure out what in OpenSSL matches to DBMS_CRYPTO. It's just a matter of getting the flags and parameters to line up now.
  16. #9
  17. Contributing User
    Devshed Novice (500 - 999 posts)

    Join Date
    Sep 2006
    Posts
    857
    Rep Power
    388

    Wink


    Originally Posted by d3bruts1d
    I found out that our password management system is basically able to provide us anything that is available via OpenSSL. Why they are only currently doing the Apache APR1-MD5 and crypt(1) formats is beyond me.

    The good news is, if I can figure out what lines up in OpenSSL to a method that can be reproduced via DBMS_CRYPTO I should be good. The bad news is, I have to figure out what in OpenSSL matches to DBMS_CRYPTO. It's just a matter of getting the flags and parameters to line up now.
    Easy, code your own clone of OpenSSL SHA-1 or SHA-2

    Comments on this post

    • Jacques1 disagrees : Sorry, but this is very bad advice.
    • d3bruts1d disagrees : If I could do that, I wouldn't be posting here asking for help.
  18. #10
  19. --
    Devshed Expert (3500 - 3999 posts)

    Join Date
    Jul 2012
    Posts
    3,959
    Rep Power
    1014
    Nonsense. Sorry, but I don't think your comments are very helpful. SHA is absolutely inappropriate for storing passwords. And tinkering with some home-made implementation would be simply reckless. We're talking about highly sensitive data here. This is definitely not the right time for trying out your first attempts at programming a crypto algorithm. What if he fails and ends up exposing all passwords? Will you take the responsibility?



    @ d3bruts1d:

    I think you should talk to the people in charge or your company's security person.

    Given the very special requirements and limitations, you'll need somebody who actually knows this stuff and can comment on the problems:

    • Does your company really wanna run around with a bunch of ancient hash algorithms which offer no protection against current hardware? If this comes out, you'll have a lot of explaining to do.
    • Do you really have to (ab)use a database system for cryptography? This is simply not what DBMS are made for. You may be able to find some third-party implementation of a password hashing algorithm, but it will come with all kinds of trouble: Is it trustworthy? Reliable? How to deal with the risk of Oracle putting the plaintext passwords into the database log? In general, cryptography should always be done in the application. Java, PHP etc. all come with well-tested standard tools for cryptography.

    In other words: Save your *ss. I wouldn't want to be the one responsible for the next password leak.

    Comments on this post

    • d3bruts1d agrees : Thanks for the help. Your points are valid and well taken.
    The 6 worst sins of security ē How to (properly) access a MySQL database with PHP

    Why canít I use certain words like "drop" as part of my Security Question answers?
    There are certain words used by hackers to try to gain access to systems and manipulate data; therefore, the following words are restricted: "select," "delete," "update," "insert," "drop" and "null".
  20. #11
  21. No Profile Picture
    Registered User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Aug 2004
    Posts
    11
    Rep Power
    0
    Originally Posted by Jacques1
    <...snip...>Do you really have to (ab)use a database system for cryptography? This is simply not what DBMS are made for. You may be able to find some third-party implementation of a password hashing algorithm, but it will come with all kinds of trouble: Is it trustworthy? Reliable? How to deal with the risk of Oracle putting the plaintext passwords into the database log? In general, cryptography should always be done in the application. Java, PHP etc. all come with well-tested standard tools for cryptography.
    Sadly, Oracle APEX doesn't offer any real method for cryptography aside from the functions in the databse. We have been using PHP, but even then it's main function is based on crypt(1).

    Honestly, I had not considered the fact that if I passed the password to the DB to allow it to do the hash then that would be available in the logs. Thanks for pointing that out, I really should have seen that. Looks like I'm back to square one.
  22. #12
  23. --
    Devshed Expert (3500 - 3999 posts)

    Join Date
    Jul 2012
    Posts
    3,959
    Rep Power
    1014
    Like I said, you need to talk to the person in charge or the security guru of your company.

    Your problem may sound like a technical issue, but it's not. It's a fundamental decision regarding the security policy of your company. It's a choice between "We give a damn about the security of our customers" and "We do everything we can to protect them". Depending on your job position, this isn't something you can or should decide on your own.
    The 6 worst sins of security ē How to (properly) access a MySQL database with PHP

    Why canít I use certain words like "drop" as part of my Security Question answers?
    There are certain words used by hackers to try to gain access to systems and manipulate data; therefore, the following words are restricted: "select," "delete," "update," "insert," "drop" and "null".

IMN logo majestic logo threadwatch logo seochat tools logo