Password Hygiene for Freelancers Who Hold Client Logins

A solo freelancer with six clients holds about forty sets of credentials. The one-hour setup, and the rules for handling client access professionally.

Freelancers hold more keys than they realise

Count them honestly: client CMS logins, an ad account, a payment processor, two hosting panels, a shared inbox, a design tool seat, an analytics property, an old staging server nobody decommissioned. A solo freelancer with six clients is often holding forty sets of credentials — and is a more attractive target than any one of those clients, because compromising you compromises all of them.

This is not a reason for anxiety. It is a reason for a system, and the system takes about an hour to set up.

What actually makes a password strong

Two things: length and randomness. Nothing else.

A password of 16 random characters is beyond brute force with current hardware. A clever human-made password of 8 characters with a $ for an s is not — that substitution is in every cracking dictionary, and has been for twenty years.

Length beats complexity because each additional character multiplies the search space. The mistake is generating something long and then reusing it, which returns the security to zero the moment any single site is breached.

Use the free password generator to produce them. It uses the cryptographically secure random generator built into your browser, generates locally, and stores and transmits nothing.

Reuse is the real vulnerability

Almost no client account is lost to a cracked password. They are lost to credential stuffing: an unrelated service is breached, the email-and-password pair appears in a public dump, and automated tools try that pair against hundreds of other services. One reused password is how a leak from a forum you forgot about becomes access to a client’s ad account with a live budget.

So the rule is one unique password per account, with no exceptions for “unimportant” logins. Which is only feasible with a manager.

The one-hour setup

  1. Install a password manager. Any reputable one. The choice matters far less than the fact of having one.
  2. Create one long passphrase for the vault — four or five unrelated words, memorised, written nowhere. This is the only password you will ever type from memory.
  3. Turn on two-factor authentication on email, banking, payment processor, hosting and the manager itself. Email first: whoever controls your inbox can reset everything else.
  4. Prefer an authenticator app over SMS. SIM-swap attacks are cheap and common.
  5. Save the recovery codes in the vault, and one printed copy somewhere physical.
  6. Then replace passwords in order of damage: email, payments, hosting, client admin accounts, everything else. Do not attempt all forty in one sitting; replace as you log in over the following weeks.

Client credentials need their own rules

This is where freelancers create risk for other people, and where a professional habit is genuinely a selling point.

Never accept a password over email or chat. Ask the client to create you your own account instead. If a shared secret is unavoidable, use a one-time secret link that expires after viewing, or the manager’s sharing feature.

Always ask for your own named account with the lowest permission level that lets you do the work. Editor, not administrator, unless administrator is genuinely required. It protects the client, and it protects you from being blamed for a change you did not make.

Never store client credentials in a spreadsheet, a notes app, or a browser profile you sync across devices. The vault or nothing.

Off-board deliberately. When a project ends, ask them to revoke your account and confirm in writing that you no longer hold access. Say it in the closing email — it reads as competence, and it removes your liability for anything that happens on that account afterwards.

Handling this in writing, as part of onboarding and closing, is what separates it from an ad-hoc favour:

What to stop doing

Rotating passwords every 90 days for no reason — the guidance changed years ago, because forced rotation produces Summer2026! followed by Autumn2026!. Change a password when there is a reason: a breach, a departing collaborator, a shared secret, a suspicion.

Security questions answered truthfully. Your mother’s maiden name is public information. Generate a random string for the answer and store it in the vault.

Storing 2FA recovery codes in the same email account that 2FA protects.

Frequently asked questions

Is a password generated in a browser really random?
Yes, when it uses the Web Crypto API, which this tool does. It is the same class of generator used for cryptographic keys — not Math.random().

Does the tool see or store what it generates?
No. Generation happens locally in your browser. Nothing is sent anywhere and nothing is retained after you close the tab.

How long should a password be?
16 characters as a default; 20 or more for email, banking and your password vault.

Are passphrases as good as random strings?
For anything you must memorise, yes — four or five unrelated words are strong and rememberable. For everything else, let the generator produce random strings and let the vault remember them.

A client insists on emailing me the password.
Accept it, change it immediately after your first login, and tell them you have done so. Then ask for your own account for the next project.


One vault, one memorised passphrase, 2FA on the accounts that can reset the others, and a written record of which client access you hold. That is the whole system.