4 Replies Latest reply: Oct 29, 2012 7:07 AM by Matschbirne RSS

    Rich client authentication

    Matschbirne
      Hi security guys,

      we're just redesigning one of our applications. The old application is a java-written rich-client that has the database connection details hardcoded (ugh, I know...). For the new software I wanted to encourage our developers to think about a middleware that does all the busines logic, but they refuse this because it's too much work for them. My fear is: The rich client resides on the endusers workstation. No matter how I store the database connection details in the application, the user can potentially access them:

      - Store it in configfiles: The user can read then
      - Store them in configfiles and encrypt it: The user could read from application memory just before the application logs on to the database and grab it from there
      - Retrieve it from external source: Same here.
      ...

      I guess this list can be endless. No matter how hard I think of this, I can find no way to secure this information.

      I guess I'm not alone in the world with this problem, so there must be a foolproof way out there to solve this. I hope you can help me to get an idea about this.

      Regards
      Thomas
        • 1. Re: Rich client authentication
          Harm Joris ten Napel-Oracle
          Hi Thomas,

          please have your developers look at using the secure external password store (an Oracle wallet) that can be used to store database credentials securely:

          note 403744.1 How to Use an External Password Store with the OCI JDBC Driver

          greetings,

          Harm ten Napel
          • 2. Re: Rich client authentication
            Matschbirne
            Hi Harm,

            thanks for your answer, but I am unsure how will this help? If a user has an External Password Store stored on his client, he can connect to the database even easier, can't he? Wouldn't it mean the user can simply connect like "connect /@prodalias" using sqlplus without even the need to reverse engineer the user/password combination out of the application?

            Regards
            Thomas
            • 3. Re: Rich client authentication
              andrewmy
              If i read the requirement correctly you basically want to let your users to run the client but without installing the client software on each PC where the innards are exposed.

              If changing the way the application connects to the db is out of the question, then you can deploy the client via something like XenApp which removes the need to install it into each PC thus hiding the internals from the users. This still doesn't prevent the cunning from trying to grab the connection info from memory though, but it may make it harder to extract the connection information than having the code sitting on each PC.
              • 4. Re: Rich client authentication
                Matschbirne
                Changing the way the application connects is my intention. We're completely redesigning the whole application, so everything's open. The only thing that is not to be discussed is a middlerware. Our developers do not want a middleware.

                Application virtualization as you mentioned is indeed a topic. But the point that makes me feel insecure is that users can still "read the memory", so as you already mentioned the nescessary work to get the connection information is indeed higher, but it's not impossible.