Skip to main content
Shearman Fine Arts Building at Dusk

Guidelines for Database Passwords

Guidelines for Database Passwords

Guidelines for Database Passwords

  1. Purpose

    These guidelines state the requirements for securely storing and retrieving database usernames and passwords (i.e., database credentials) for use by a program that will access a database running on one of McNeese State University's networks.

    Computer programs running on McNeese State University's networks often require the use of one of the many internal database servers. In order to access one of these databases, a program should authenticate to the database by presenting acceptable credentials. The database privileges that the credentials are meant to restrict can be compromised when the credentials are improperly stored.

  2. Scope

    These guidelines apply to all software that will access a McNeese State University, multi-user production database.
  3. Guidelines

    1. General

      In order to maintain the security of McNeese State University's internal databases, access by software programs, with the exception of server-side code should be granted only after authentication with credentials. The credentials used for this authentication should not reside in the main, executing body of the program's source code in clear text. Database credentials should not be stored in a location that can be accessed through a web server.

    2. Specific Requirements
      1. Storage of Database User Names and Passwords
        1. Database user names and passwords may be stored in a file separate from the executing body of the program's code. This file should not be world readable.
        2. Database credentials may reside on the database server. In this case, a hash number identifying the credentials may be stored in the executing body of the program's code.
        3. Database credentials may be stored as part of an authentication server (i.e., an entitlement directory), such as an LDAP server used for user authentication. Database authentication may occur on behalf of a program as part of the user authentication process at the authentication server. In this case, there is no need for programmatic use of database credentials.
        4. Database credentials may not reside in the documents tree of a web server.
        5. Pass through authentication (i.e., Oracle OPS$ authentication) should not allow access to the database based solely upon a remote user's authentication on the remote host.
        6. Passwords or passphrases used to access a database should adhere to the Guidelines for University Passwords.
      2. Retrieval of Database User Names and Passwords
        1. Database user names and passwords should be read from the file immediately prior to use if stored in a file that is not source code. The memory containing the user name and password should be released or cleared immediately following database authentication,
        2. The scope into which you may store database credentials should be physically separated from the other areas of your code, (e.g., the credentials should be in a separate source file). The file that contains the credentials should contain no other code but the credentials (i.e., the user name and password) and any functions, routines, or methods that will be used to access the credentials.
        3. For languages that execute from source code, the credentials' source file should not reside in the same browseable or executable file directory tree in which the executing body of code resides.
      3. Access to Database User Names and Passwords
        1. Database passwords used by programs are system-level passwords as defined by the Guidelines for University Passwords.
        2. Developer groups should have a process in place to ensure that database passwords are controlled and changed in accordance with the Guidelines for University Passwords. This process should include a method for restricting knowledge of database passwords to a need-to-know basis.
  4. Definitions

    Computer language
    A language used to generate programs.
    Something you know (e.g., a password or pass phrase), and/or something that identifies you (e.g., a user name, a fingerprint, voiceprint, retina print). Something you know and something that identifies you are presented for authentication.
    The level of privilege that has been authenticated and authorized. The privileges level at which to access resources.
    Executing body
    The series of computer instructions that the computer executes to run a program.
    An algorithmically generated number that identifies a datum or its location.
    Lightweight Directory Access Protocol, a set of protocols for accessing information directories.
    A collection of computer language instructions grouped together either logically or physically. A module may also be called a package or a class, depending upon which computer language is used.
    Name space
    A logical area of code in which the declared symbolic names are known and outside of which these names are not visible.
    Software that is being used for a purpose other than when software is being implemented or tested.
  5. Revision History

    Thu Dec 20, 2013