Secure Credential Management and Script Hardening

Why Plaintext Passwords Are a Critical Risk

Every time a password appears in a shell script, it is readable by anyone who can view that file, inspect process environment variables, or read shell history logs. In a database environment, a compromised credential can expose entire schemas, customer records, and backups. Professional database administrators treat credential exposure as a high-severity vulnerability—not merely bad style.

This lesson applies layered controls to eliminate plaintext passwords from your Bash automation library. The same defense-in-depth philosophy used in physical security—never relying on a single lock—applies here: no single technique is foolproof, so you combine several.

Layer 1: Environment Files with Restricted Permissions

A `.env` file stores key-value pairs such as `DB_PASS=secret` outside of the script itself. The script sources the file at runtime with `source /path/to/.env` or `. /path/to/.env`. The critical step is setting the file's permissions so only the owning user can read or write it:

```bash

chmod 0600 ~/.env

```

Mode `0600` means owner read/write, no access for group or others. Store the `.env` file outside version-control directories and add it to `.gitignore`. Never commit it to a repository.

Always validate that the file exists and is not world-readable at the top of every script that sources it:

```bash

[ "$(stat -c '%a' ~/.env)" = "600" ] || { echo "Bad .env permissions"; exit 1; }

. ~/.env

```

Layer 2: PostgreSQL `.pgpass` and `scram-sha-256`

PostgreSQL's `.pgpass` file (`~/.pgpass` on Linux) stores connection credentials in the format `hostname:port:database:username:password`. The `libpq` library reads this file automatically when no password is supplied on the command line. Required permissions:

```bash

chmod 0600 ~/.pgpass

```

If permissions are wider than `0600`, PostgreSQL ignores the file entirely.

For stronger authentication, configure `pg_hba.conf` to require `scram-sha-256` instead of `md5` or `trust`:

```

host all dbauser 127.0.0.1/32 scram-sha-256

```

For certificate-based authentication (the strongest client-auth method), use the `cert` method in `pg_hba.conf` and supply a client certificate signed by the server's CA. No password travels over the network at all. Your backup script can then call `pg_dump` without any credential flag—the certificate and private key handle identity.

Layer 3: Oracle Wallets

Oracle Database uses an encrypted wallet (managed with `mkstore` or the ORAPKI utility) to store connection credentials. The `sqlplus /@TNS_ALIAS` syntax instructs SQLPlus to retrieve the password from the wallet rather than accepting it as an argument. The wallet directory must be protected:

```bash

chmod 0700 /path/to/wallet

```

Oracle's wallet approach aligns directly with the Oracle DBA CA exam's security domain, which expects candidates to know how to avoid embedding passwords in scripts and connection strings.

Layer 4: Secrets Scanning

Before committing or deploying any script, run a grep scan across your automation library:

```bash

grep -rn 'password\|PASSWORD\|PGPASSWORD' ./scripts/

```

A clean library returns zero hits. This is a mandatory gate in this lesson: if the scan finds anything, refactor before moving on. In professional pipelines this scan is automated—tools such as `git-secrets` or `truffleHog` run at commit time. For this course, the manual `grep` scan achieves the same learning goal.

Script Hardening Practices

Beyond credential management, harden every script with these header directives:

• `set -euo pipefail` — exits on any error, treats unset variables as errors, catches pipeline failures.
• Validate every external file (`.env`, `.pgpass`, wallet path) before use.
• Redirect error output to a log file owned by the service account, not world-readable.
• Use absolute paths for all binaries to prevent PATH-hijacking.

Physical and Digital Security: A Parallel

OSHA's Lockout/Tagout (LOTO) standard (29 CFR 1910.147) requires workers to isolate and de-energize equipment before servicing it, so that no one else can accidentally re-energize it during the work. The database equivalent is least-privilege service accounts: a backup service account should have `SELECT` and `pg_dump` rights only—not `SUPERUSER`. If that account is compromised, the blast radius is limited, just as LOTO limits injury risk to the worker performing maintenance.

Additional physical controls that complement digital script security include:

• Screen-lock policy: Unattended terminals must lock automatically. An unlocked screen can expose a running script or its output.
• Physical server access controls: Server rooms use badge access so that only authorized personnel can reach hardware where credential files reside.
• Least-privilege accounts: Service accounts for scheduled scripts should hold only the database roles they need—nothing more.

Completing the OSHA security checklist in this lesson connects these principles explicitly so you can explain digital security decisions in physical-safety language—a skill valued in team environments where not everyone has a technical background.

Connecting to Exam Objectives

• Oracle DBA CA: Security domain covers wallet configuration, privilege management, and avoiding credential exposure in scripts.
• Microsoft DP-300: Covers securing Azure SQL and SQL Server connections, managed identities, and least-privilege principles—direct parallels to `.env` and certificate authentication.
• PostgreSQL CE (EDB): Covers `pg_hba.conf` authentication methods including `scram-sha-256` and `cert`.
• DAMA CDMP Associate: Data security knowledge area addresses access control, authentication standards, and data protection policies.