Storing passwords and keys properly

The commonest mistake in learning projects

You open a candidate's repository and there in the code is a database connection string with a real password. Or an access key for a third-party service.

It ruins the impression instantly, because it shows someone not thinking about consequences. And it takes ten minutes to fix.

The rule

Anything secret lives in environment variables, not in code.

A secret is a password, an access key, a connection string, a session secret, any token.

How it's done

Create a variables file at the project root:

DATABASE_URL=postgresql://user:password@localhost:5432/notes
API_KEY=abcdef123456

Add it to your ignore list without fail. That's the crucial step; without it the rest is pointless.

Read from it in code:

import os
database_url = os.environ["DATABASE_URL"]

Square brackets rather than a safe lookup with a default: let the program fail at startup with a clear error if the variable is missing. Better than running incorrectly.

A sample file

Alongside it, place a sample with no values:

DATABASE_URL=
API_KEY=

That file does go into the repository. It tells whoever opened your project what needs filling in to run it.

A small thing that markedly improves the impression a repository gives.

On a server

Variables are set in the platform's settings, or in a file readable only by the relevant user. Permissions on such a file: owner read only.

In containers they're passed at run time rather than baked into the image: images can end up in public registries.

Storing users' passwords

A separate topic where mistakes are expensive.

Never store passwords in plain form. Not even in a learning project.

Don't encrypt them. Encryption is reversible, which means a leaked key leaks every password.

Use dedicated password hashing functions. They're deliberately slow, which makes brute force uneconomic, and they add random salt to each password themselves.

Practically: take a proven library for your language and don't invent your own. Home-made password protection is a reliable way to make things worse.

When a key has already leaked

The order matters:

1. Rotate the key immediately. Before anything else. A key that reached a public repository should be considered exposed: automated scrapers find such things within minutes.

2. Check whether it was used. Services usually keep access logs.

3. Only then clean the history. Deleting it in the latest commit doesn't help: the key remains in every earlier one. Specialised tools exist, and for a small learning repository it's sometimes simpler to start a new one.

That order is essential. People often begin with cleaning history and spend an hour on it while the key keeps working.

A quick audit of your own projects

Right now, open your repositories and search them for "password", "secret", "token", "key". Five minutes, and the findings can be unpleasant — better to find them yourself than to hear about them at an interview.