Database Passwords in Git History: What Rotation Does

Rotating a database password makes the old password unusable only if the database or its authentication system actually invalidates it; it does not remove the exposed value from Git history. Treat the credential as compromised, rotate it, check for unauthorized access, and separately remove or restrict the secret in repositories and related systems.

Why rotation does not erase Git history

Git records project changes as a chain of commits. If a password was committed, it may remain in the commit that introduced it and in later repository history, even after someone deletes it from the current configuration file. Deleting the line creates a new commit; it does not rewrite earlier commits.

That means a person who can inspect the repository may be able to find the old value by browsing or searching the history. Copies may also exist in forks, clones, backups, build logs, code review systems, or archived repository data. Removing a secret from the main branch is useful, but it is not the same as making every existing copy disappear.

Rotation changes the credential’s validity, not its historical existence. If the database rejects the old password after rotation, finding that old string later should not grant access through that password. But an attacker may already have used it, and the secret may have been reused elsewhere.

What happens when you rotate the password

The practical result depends on how the database and applications handle authentication. When a password is changed for a database account, new connections generally need the replacement credential. Existing connections may remain open until they disconnect, expire, or are terminated; changing a password does not automatically guarantee that every session is closed.

Applications, scheduled jobs, migration tools, and developers’ local environments may still hold the old value. They can start failing when they open new connections. Update each legitimate consumer through its normal secret-management process, then verify that it can connect with the new credential.

Some systems support overlapping credentials or separate accounts, which can make a gradual change possible. Others require a direct change that can briefly interrupt dependent services. Follow the database platform’s documented behavior rather than assuming a password change instantly ends every session or updates every client.

Respond in a safe order

If a real password was committed to a repository accessible beyond the people who need it, act promptly. Avoid pasting the secret into tickets, chat, or incident notes while coordinating the response. A typical sequence is:

1. Revoke or rotate the exposed credential. Use the database’s supported controls, and confirm that the old password no longer authenticates. If the password was reused, change it wherever else it was used.
2. Review access and activity. Check available database authentication logs, audit records, and account activity for unfamiliar connections or changes during the exposure period. Preserve relevant evidence and follow your organization’s incident process.
3. Update authorized applications. Replace the credential in the approved secret store or deployment configuration, restart or reload consumers where needed, and check connection health and error logs.
4. Reduce the account’s reach. Review whether it has only the permissions and network access it needs. If there is concern about misuse, consider disabling the account or terminating active sessions using the database’s documented procedures.
5. Clean the repository and other copies. Remove the secret from the current files and assess whether history rewriting is appropriate. Coordinate before rewriting shared history, and account for forks, clones, caches, and backups.

Rotation should come before cosmetic cleanup: history rewriting cannot invalidate a password that is still active. Conversely, cleanup remains worthwhile after rotation because it reduces accidental rediscovery and helps prevent the obsolete value from being copied into new systems.

Removing the secret from Git history

For a private repository with a small, coordinated set of users, rewriting history can replace commits that contain the secret. Current Git history-rewriting tools can remove a file or replace a known text value across commits. The exact method depends on the repository and what was exposed. Do not assume that deleting the current file or adding it to .gitignore changes old commits.

History rewriting changes commit identifiers. Contributors may need to re-clone or carefully reconcile their branches, and any open work based on the old history can become difficult to merge. Coordinate the rewrite, communicate the new repository state, and prevent old copies from being pushed back to the shared remote.

Rewriting is not a guarantee of total erasure. A hosting service may retain cached or internal copies, and other people may already have cloned or forked the repository. Contact the host’s support or follow its documented procedures if sensitive data remains accessible after a rewrite. For a public repository, assume the credential was copied and prioritize revocation over trying to make every copy disappear.

Also check places beyond Git commits: pull-request diffs, issue comments, CI output, deployment logs, package artifacts, and configuration files in other repositories. A cleanup that changes only one branch may leave the same value elsewhere.

Preventing another credential leak

Keep database passwords out of source code. Applications commonly read secrets at runtime from an environment-specific secret store or another controlled configuration mechanism. Avoid committing populated local environment files; a sample configuration can document required variable names without containing real values.

• Use separate credentials for development, testing, and production rather than sharing one password.
• Give application accounts the minimum database permissions they need, and avoid using an administrator account for routine application connections.
• Enable repository secret scanning or pre-commit checks where available. These can catch some accidental commits, but they cannot prove that a repository is secret-free.
• Limit repository access and protect build and deployment logs, since credentials can leak through commands, debugging output, or copied configuration.
• Have a documented rotation and incident process so teams know how to update consumers and verify the old credential is rejected.

A scanner alert is a signal to investigate, not a substitute for rotating a valid exposed password. Likewise, a password that looks random or is in a private repository should not be treated as safe once it has been committed to a place where it was not meant to be stored.

Frequently Asked Questions

Does deleting a password from a file remove it from Git history?
No. A normal commit records the deletion in the latest version, but older commits can still contain the password. Removing it from history requires rewriting commits, and copies may remain elsewhere.

Is rotating the password enough?
Rotation is the essential step for making an exposed credential unusable, provided the old credential is actually invalidated. Also check for misuse, update legitimate clients, and address repository history and other copies.

Can someone use the old password after rotation?
Not if the database has invalidated it and the password is not valid through another account or service. Confirm the behavior in the specific system; existing sessions may not be closed just because new logins require a different password.

Should I rewrite Git history after rotating?
Often it is useful, especially to reduce exposure and prevent future users from finding the value. Weigh the benefit against disruption to collaborators, and do not treat rewriting as a replacement for revocation.

What if the repository was public?
Assume the password may have been copied. Revoke it promptly, review available access records, update dependent systems, and then consider history cleanup. Removing the value from the public branch cannot recall clones or screenshots.

Related

• Is CVS Trying to Be More Like Costco and Marshalls?
• Abyss Tier List: How to Rank Characters and Teams
• Python Hackathon Platform: What SQLite Actually Handles