Secrets in the open

A secret is any value that gives access to an account: a password, a secret key, the login of an admin screen. It stays secret only while you know exactly who has it. That's the whole test.

Most secrets don't leak through hacking. They leak through ordinary tools that everyone uses every day:

• A festival's ticketing password is pasted into the WhatsApp group of its 40 volunteers, "so that anyone can print the tickets tonight".
• A dentist's booking software password is on a sticky note on the screen. The note appears in a photo of the new waiting room on the practice's Instagram.
• A developer pastes a key into a ticket in the issue tracker, so that a colleague can test something.

In each case, nobody meant any harm, and nothing bad may have happened yet. But nobody can say any more who has the secret. Someone may have forwarded the message, taken a screenshot, or lost a phone with the chat on it. So the rule is simple: once you can't tell who has read a secret, treat it as leaked. The word for this is compromised.

Your portfolio has secrets too: the passwords of your hosting account, your domain name and your form service, and of the email account that receives all their messages. The same rule applies to them.

The usual reaction to a leak is to delete the message, the document or the file. It feels like a fix, but it isn't. Deleting removes the original from view. It doesn't touch the copies, and a message or a document starts making copies as soon as it exists.

A message in a group chat appears in a notification on every member's phone. It stays in the chat's search, and in each person's backups. Someone may have taken a screenshot or forwarded it. A shared document keeps its version history, and anyone who opened it may have downloaded it. A file in a code repository stays in the project's history. Git keeps every past version, so deleting the file today leaves it in yesterday's commit. Public repositories are worse: bots search them for passwords and keys all day, and find new ones within minutes.

So there is only one fix. Change the password, or revoke the key and create a new one. Then every old copy stops working, wherever it is. This is called rotating the secret. After that, update everything that uses it, such as the site's settings. Otherwise the site stops working too.

A bike shop discovers that the password of its online shop's admin screen has been in the welcome guide of every seasonal worker since April. The guide is a PDF, sent by email to about twenty people. What now?

First, change the password today, before you investigate. Every hour that the old one works is an hour in which someone can use it. Then update everything that uses it, so that it keeps working with the new one.

Next, check for signs of use. Most services keep logs, a record of each login and action, with the time and where it came from. Ask whoever runs the service to check them for logins since April. Then activate two-factor authentication on that account, so that a password alone is no longer enough to log in.

Last, think about the data behind the password. The admin screen shows customers' names, addresses and orders. If someone may have read them, that's a personal data breach. Tell whoever handles GDPR in the company at once, because a breach may have to be reported to the CNIL within 72 hours.

If an agency or a freelancer exposed the secret, ask them to fix it before you sign the acceptance and pay the last invoice. After that, they have much less reason to hurry.

Secrets need a proper home, where each one is shared with named people and you can see who has what.

For passwords, that home is a password manager, such as Bitwarden, 1Password or Dashlane. It keeps each password encrypted and shares it only with the people you choose. You can remove someone in one click. For the keys that a site's code uses, the home is the hosting service's secret settings. The code reads them there, and nobody has to paste them anywhere. On your computer, your agent keeps them in a .env file, which never goes into the repository.

Better still, avoid shared passwords. When each person has their own account on each service, you can remove one person the day they leave, without changing everyone's password. And the logs show who did what. A shared account hides that.

Then activate two-factor authentication on the accounts that matter most: hosting, domain, payments and email. The email account matters most of all, because whoever reads your email can reset most of your other passwords.

The example below shows two welcome emails for a new volunteer on a theatre's web team. The first one gives the same password for everything, and asks the volunteer to forward it. The second one gives the volunteer their own invitations, and says where the shared passwords are kept.

Hiding a secret is only half the job. The other half is limiting what it can do. Every password and every key allows a set of actions: reading data, adding it, changing it, deleting it, managing other accounts. The right access allows only what the task needs, for as long as it needs it. This principle is called least privilege.

Take a museum's website. A photographer adds pictures of the new exhibition, so she needs an account that can add images. She doesn't need one that can delete pages or invite other users. A translator needs to edit the English pages, not the shop's prices. A newsletter tool needs to add subscribers to a list, not to read the whole customer database. The accountant needs to read the shop's invoices, not to change them: that's read-only access.

Nobody here is dishonest, and that's not the point. Honest people make mistakes, get their own accounts hacked, or lose a laptop. An AI agent can misunderstand an instruction. With the smallest access, the worst case stays small. Your own coding agent needs your portfolio's folder, not the password of your email.

Most services offer roles for this, such as viewer, editor and admin. Give the admin role to two or three people only, and protect it with two-factor authentication. Separate, limited accesses can also be removed one at a time, the day a contract ends.

Ask these questions at the start of a project, at every handover, and whenever someone asks for access.

Ask the team, the agency or the freelancer where the passwords and keys live, and who can read them. You want to hear "in a password manager" and "in the hosting's secret settings", with a list of names. If a secret was ever in a document, a chat, an email or the code, ask whether it has been changed since. "We deleted it" is not an answer. If you're about to accept a delivery, ask for this before you sign.

When someone asks for access, whether a colleague, an agency, a tool or an AI agent, don't simply say yes or no. Ask what exactly it needs to do, and for how long. Then give the narrowest role that does the job, straight away, so that the work isn't blocked. Write down who has what, and remove it when the job ends.

For your portfolio, check three things today. Is two-factor authentication active on your email, your hosting and your domain? Is a key anywhere in your repository, in any past version? And does your agent have more access than it needs?