Suggestion on password in script file

  • Harrygunner

    First of all, I want to thank you and your crew
    on the great work achieved in hsqldb.

    I want to discuss the issue with having the database
    password in the script file.

    Hashing the password or compressing the script file do
    nothing to address this problem of accessing the

    The concern:

    With an editor, search for 'PASSWORD', then, remove
    the password, leaving:


    Then, with one of the tools that comes with hsqldb,
    anyone can look at the contents of the database.

    (If the script file is compressed, then, unzip it,
    remove the password, then, zip it. Same problem.)

    Proposed solution:

    Replace the PASSWORD contents with ASCII
    converted encryption of known text. The encryption
    would be done with the hash of the user's password as
    a key.

    If the user/password combination entered recovers the
    known text, access is granted.

    This way, passwords are not viewable and altering or
    removing the password would lead to denial of access.

    A user might try to become 'SA' by replacing SA's
    encrypted portion with his/her encrypted portion.  So,
    the known text must include the user's id.

    Someday, the script file and the log file needs to be
    encrypted before hitting the hard drive. But, once
    again, you've done a lot of good work and this small
    change may help with this one issue.

    • Blaine Simpson
      Blaine Simpson

      I realize that there are cases where it doesn't work (like where
      you are embedding HSQLDB into some container that can't be
      secured, like most app servers), but if you're running in UNIX, it's
      extremely easy to lock down the entire database directory if
      you can run a HSQLDB Server from a dedicated user account.
      If you don't have a team of people doing administration,
      having the password in there unencrypted is not a security
      risk, since oly the administrators can view it.

      (Same may be possible in Windows, but the XP directory
      properties Security screen sure isn't intuitive--  As in, how
      the hell do I permit access to only one user?)

      Regardless of how you hide the HSQLDB files, you still need
      to encrypt the JDBC pipe if it's inter-process.  The TLS feature
      covers that.

      • Blaine Simpson
        Blaine Simpson

        3 Other weaknesses, and a clarification of the generally accepted goals for persisted password encryption.

        #1 may be due to me not understanding your intention, or maybe you can
           think of a work-around for it.

        > 'So, the known text must include the user's id'.

        (If I understand your post, by 'known text', you mean the text that must
        be supplied in the authentication attempt; as opposed to publicly known
        encoding keys, salts, desired account, etc.).
        Which user ID?  Must be talking about a HSQLDB user Id, since we aren't
        about to tie HSQLDB authentication to OS accounts.  The only HSQLDB
        account it could be is the 'target' HSQLDB account, i.e., what we want
        access to (since there is no other HSQLDB user Id involved if we are
        logging in to HSQLDB for the first time)-- in this case 'SA'.  So, what
        good is to to encrypt password 'secret' as 'SA_secret' or similar,
        since (as Campbell pointed out), it will be public knowledge that you
        just add 'SA_' to the password.  Example of using your suggestion.
        Existing .script entry:

            CREATE USER SA PASSWORD 'XYZ123'    ('XYZ123' is encrytpion of 'SA_secret')

        Anybody with write permissions can change this to:

            CREATE USER SA PASSWORD 'ABC976'    ('ABC976' is encrytpion of 'SA_forge')

        #2 This applies to any solution which satisfies your intended goal

        We assume that you somehow achieve your goal of making it 100%
        impossible to make new Admin accounts or to change account passwords
        without knowing an existing Admin password.  (I agree with
        Campbell that due to Java classloading, open source, etc, there is no
        way to accomplish this from within HSQLDB, but maybe with FS encryption
        or other OS support, or maybe there's a way we haven't thought of yet).
        This database becomes permanantely un-administerable if your DBA forgets
        the password or dies.  Every application must provide some way to
        recover the system if all passwords are lost.

        #3 Why are you so concerned about any old user giving themselves
        administrative access, but don't care that they may replace the entire
        database with whatever they want, or zero out the files completely?
        Your assumption all along is that this pesky password-changing user
        has write permission to the .script file.

            dos> cd c:\path\to\hsqldb\db
            dos> echo haha > dbname.script


            dos> cd c:\path\to\hsqldb\db
            dos> copy \docume~1\peskyuser\trojan_db\* .

        If you dont' want a user to be able to 'modify' the script file,
        then the simple and direct solution is to change the DB directory
        or files so that they are not writable to untrusted users.  You
        will need to design your application so that the JVM running the
        database (whether a Server, standalone, or whatever) has write
        perms on the data files, but untrusted users do not (except through
        the application).


        Encrpytion is obviously needed when transmitting or keying in
        passwords when there may be eaves-droppers.  But in our current
        discussion, we are concerned only with _storing_ ecrypted passwords.

        The general need for encrypting _stored_ passwords is not to prevent
        them from being changed, but to prevent them from being SEEN by
        _authenticated_ users.  If you don't want the files to be _changed_ by
        unauthenticated users, then protect the files!

        For example, passwords used to be stored directly in the protected
        file /etc/passwd in UNIX.  This policy was not changed because
        non-trusted users could somehow get access to these passwords, but
        because we want to prevent even administrators from viewing all the
        users' passwords.  An example at the other extreme are RC files for
        ftp, SqlTool, etc.  These are personal files that contain passwords
        for 'my accounts'.  There is no reason at all to encrypt these
        passwords since only _I_ may see or change them.  Databases also
        generally do not need user passwords to be hidden from adminstrators.
        Who cares if the DBA's can see all of the users' passwords.

    • Harry:

      First, thanks for the complements and the concern.

      Now, not to be negative, just factual, this has been discussed at great length, many many times and at very great length and detail in threads from long ago.

      The ultimate conclusion of all those discussions is that, short of best-practices physical security, social-exploit prevention and bios-level file encryption or at least well administered file security, as Blaine discusses above, there's simply no point to do better than compressed script file to keep casual poking about to a minimum.

      Although you'll just have to trust me (I'm not launching into another long diatribe), anything in between can be formally shown to produce no real increase in security, yet requires lots of work, maintenance, and likely complicates/slows down the engine.

      The simplest point in case is that anyone can obtain the source code to HSQLDB, patch it to turn password checking off completely and then open any set of HSQLDB database files to which they have file system access.

      It's just as easy to path HSQLDB to turn of ADMIN role checking, allowing anyone to do anything they like in the database, once they have logon.

      Even further, since Java is a virtual machine with dynamic class loading and the possibility to replace system classes using prepend or append command line arguments (indeed, Java platform source from Sun and several other implementors is available), it's quite possible to introduce a class loading interceptor into a JVM to alter the behavoir of a product, even without recompiling it directly.

      That is, any user can break most attempts at Java security (except true end-to-end strong encryption, which is useless, since nobody gets to see any real data), as long as they can run a java application in the JVM of their choice, with control over startup paramters.

      End of discussion (sorry...getting close to long diatribe warning alert...:)

      Now, with that said, I also feel I have to point out a flaw in your logic.

      Specifically, I am unclear on this portion of your post:


      This way, passwords are not viewable and altering or 
      removing the password would lead to denial of access.

      A user might try to become 'SA' by replacing SA's 
      encrypted portion with his/her encrypted portion. So, 
      the known text must include the user's id.


      I do not think this moves the issue forward, as it's still possible under your proposed scheme (indeed, any one way hashing scheme) to replace an entire user creation statement in the log.

      That is, no matter what is done regarding hashing, as long as a user has write access to the log and/or script file, then to gain access, simply add a new entry based on a desired id/pwd pair, using the (since we are open source) easily discovered hashing algorithm.

      // --

    • Harrygunner

      I am particularly concerned that a person with no
      coding ability can simply remove the password and
      gain access. I was addressing that concern
      in my post.

      I had mentioned that hashing of passwords does
      nothing to fix this. My proposal was something else

      But, this is not important. Having all information files
      encrypted is.

      I'll look to see if compression can be replaced
      with encryption similar to the way you handle
      the data file.

      As you said, it's been discussed several
      times over several years. Perhaps users
      are concerned about security.

      If Cloudscape/Derby can encrypt its files, we
      can too.