5 Replies Latest reply: Jan 11, 2013 7:44 PM by marksmithusa RSS

    Documenting passwords for Database continuity

    user599292
      First off I am not an oracle DBA.

      However from a risk/audit/compliance perspective, I attended a recent seminar whereby the DB Security speaker said it was common practice for DBA's to document passwords associated with DB servers they manage in plain text in documents. I suspect for some form of continuity.

      Some questions are:

      1) Why

      2) What do you refer to these documents as

      3) Whats the risk in not documenting passwords associated with databases and servers

      4) What passwords do you document
        • 1. Re: Documenting passwords for Database continuity
          Billy~Verreynne
          Password based security is based on the principle of using a secret, and using that secret for identification.

          It makes no sense to document that secret. Have never seen DBAs "documenting" such secrets for "continuity" (fail to grasp why continuity would be a reason).

          What some shops do is have the DBA/sysadmin record the password on a paper, stick it into a sealed envelope, and have the manager keep it. Reason: should the admin person knowing the secret not be available to perform some urgent task requiring the secret, a stand-in will need to do the task, but will require the secret to do it. (is this what you implied with continuity?)

          To be honest - I question the credentials of a DB security speaker when this person states that DBAs record passwords as plain text in documents as common practise.

          I have been doing DBA stuff in some form or another since the 80s - and have NEVER seen this "common practise" anywhere.
          • 2. Re: Documenting passwords for Database continuity
            user599292
            Hi Billy,

            yes that was my guess, the password may be required if the admin was off when that credential was requried to perform an urgent task, hence the need to record it somewhere another admin can access it. But I guess from a risk perspective its identifying where the password is, and who can access it, so it doesnt fall into the wrong hands..
            • 3. Re: Documenting passwords for Database continuity
              jgarry
              Decades ago it was common to write the password on paper and lock it in a vault.

              Years ago it was common to have a secret algorithm for creating a password, only in the heads of the dba team (like "BIGBOSSISANIDIOT" concatentated with some variant of a host name). It didn't matter so much because one could always change the password as the oracle OS owner, or one could save the hash, change the password, do what you want, then replace the hash.

              Nowadays, with remote access and hackers everywhere and extra security options so that DBA's don't have to be able to access everything and various laws and regulations, it is site-dependent, with a very large range of usage across sites. So, it depends. Some places still give vendor help desk personnel root passwords and say "fix the box." Other places have security audits, or even hacker attack teams. In the end, social engineering is the most common attack vector. Hyperhackers pwn cloud sites.
              • 4. Re: Documenting passwords for Database continuity
                Billy~Verreynne
                user599292 wrote:

                yes that was my guess, the password may be required if the admin was off when that credential was requried to perform an urgent task, hence the need to record it somewhere another admin can access it. But I guess from a risk perspective its identifying where the password is, and who can access it, so it doesnt fall into the wrong hands..
                These days having to know the password is seldom necessary for "continuity". And it has been more than a decade since I've last seen the password-on-paper-kept-safe-by-manager approach being used.

                To do maintenance on a server (o/s, web, database, etc), I simply need my public RSA key to be trusted by that server. And to gain access, I need to supply my private RSA key.

                No secrets to remember. No secret to change often, in case it is accidentally revealed/exposed. And stealing a private RSA or DSA key is significantly more complex than stealing a password.

                So to logon as SYSDBA - instead of using the SYS password to connect, I can connect as the oracle o/s user using RSA authentication via ssh to the db server - and then use trusted o/s credentials to do an "internal" connect to the database.

                Servers can also be configured for auditing and logging this - which means a detailed record exists of who logged onto the server from where. In addition, a dedicated management network can be used - with firewalls protecting it, and only allowing selected IP addresses from the intranet access to the management network for managing servers via it.
                • 5. Re: Documenting passwords for Database continuity
                  marksmithusa
                  Billy  Verreynne  wrote:
                  Password based security is based on the principle of using a secret, and using that secret for identification.

                  It makes no sense to document that secret. Have never seen DBAs "documenting" such secrets for "continuity" (fail to grasp why continuity would be a reason).

                  What some shops do is have the DBA/sysadmin record the password on a paper, stick it into a sealed envelope, and have the manager keep it. Reason: should the admin person knowing the secret not be available to perform some urgent task requiring the secret, a stand-in will need to do the task, but will require the secret to do it. (is this what you implied with continuity?)

                  To be honest - I question the credentials of a DB security speaker when this person states that DBAs record passwords as plain text in documents as common practise.

                  I have been doing DBA stuff in some form or another since the 80s - and have NEVER seen this "common practise" anywhere.
                  +1

                  Everywhere I've worked, we have a different system: from the sealed envelope in the CTO's safe, to a hidden file only accessible by a certain user on an obscure system to a password-protected Excel spreadsheet (I didn't like that one).

                  I don't know ANY DBA who records passwords in plain text in documents. They would be asking to get fired when they get audited.

                  Mark