Password Policy for Transfer Accounts

Password policy is where more security theater accumulates than anywhere else in IT. Rules that feel rigorous — a symbol, a number, an uppercase letter, a fresh password every ninety days — mostly measure how much inconvenience users will tolerate, not how hard the passwords are to break. Meanwhile the properties that genuinely stop attacks get less attention than they deserve.

Transfer servers make the problem sharper than usual, because their account list is a mix: human users who must remember their passwords, service accounts whose passwords live in configuration files and are typed by no one, and partner accounts whose passwords live inside another company entirely. One policy cannot treat those three the same way and be right for any of them.

This article — part of our Authentication on Transfer Endpoints series — builds a password policy from how attacks actually work, gives you a copy-ready version, and settles the rotation question honestly: when calendar rotation is theater, and the two cases where it is exactly right.

Know the Attacks the Policy Must Stop

A password rule is only justified if it blunts a real attack, so start with the four patterns your transfer server will actually face. You need to recognize them, not perform them — this is the defender's view.

• Online guessing. An attacker sends login attempts at your server, either hammering one account with many passwords (brute force) or trying a few very common passwords across many accounts (password spraying, tuned to duck lockout rules). Every internet-facing transfer endpoint receives this as background noise. Defenses: passwords too long to guess, plus throttling and lockouts — the machinery of our brute force protection series.
• Credential stuffing. The attacker replays username-and-password pairs leaked from breaches of unrelated services, betting the person reused the password. Defense: uniqueness — a password used nowhere else — plus screening new passwords against known-breached lists.
• Offline cracking. If an attacker steals a server's stored password data, they can run guessing software against it at enormous speed on their own hardware, with no lockouts to slow them. Defense: the server storing proper hashes (one-way fingerprints of passwords, not the passwords themselves), and — again — length, because each added character multiplies the work.
• Phishing. The human is tricked into typing the password on an attacker's page. No composition rule helps here; the honest mitigations are a second factor for interactive logins, and credentials, like SSH keys, that cannot be typed into the wrong box at all.

Notice what keeps recurring in the defense column: length, uniqueness, throttling, screening. Notice what never appears: "must contain a symbol."

Why Length Beats Complexity Theater

The strength of a password is the number of guesses an attacker needs to find it. Two things can raise that number: a bigger alphabet of possible characters (complexity) or more characters (length). They are not equal, because of how the arithmetic scales.

Adding one character multiplies the search space by the whole alphabet size — every extra character is another multiplication. Growing the alphabet helps only per-character, and here is the trap: it assumes humans use the bigger alphabet randomly. They do not. Faced with "must include uppercase, number, symbol," almost everyone produces the same shape: capital letter first, the digit and the exclamation mark at the end, an @ standing in for a. Guessing tools are built around exactly these habits — they try dictionary words with the standard decorations before anything else. The rules made the password annoying to type without making it meaningfully harder to find.

Compare two candidates. P@ssw0rd1! satisfies every classic complexity rule and falls quickly, because it is a top-ten dictionary word wearing the most predictable costume in the world. corridor-lantern-maple-tide contains no uppercase, no digits, and no symbols — many legacy policies would reject it — yet it is twenty-seven characters long, and the number of four-word combinations from even a modest vocabulary is astronomically beyond guessing. This style — several random common words — is a passphrase, and it is the practical way for a human to hold real length in memory.

Modern guidance from standards bodies has landed in the same place: require length, screen against known-bad passwords, and drop the composition rules. Your policy should too.

Humans and Machines Are Different Problems

A password rule that ignores who — or what — must reproduce the password will be wrong for someone. Transfer servers have three distinct populations.

Human accounts carry the memorability constraint, and there are exactly two honest ways to live with it. Either the human memorizes one strong passphrase in the four-random-words style, or — better — a password manager (a vault application that generates and stores passwords) remembers a long random string for them, and the human memorizes only the vault's own passphrase. What humans cannot do is memorize many strong passwords; policies that assume it manufacture sticky notes and reuse.

Service accounts — accounts used by scheduled jobs and scripts rather than people — have no memorability constraint at all. Nobody will ever type this password; it lives in a configuration store and is replayed by software. So there is no excuse for it to be anything but long and fully random: twenty characters or more straight from a generator. A human-styled password on a machine account is strength left on the table for no benefit. Where the protocol allows it, machines should skip passwords entirely in favor of SSH keys — see SFTP authentication — but the passwords that remain should be maximal.

Partner accounts are service accounts that live in someone else's building. Same generation rule — long, random, machine-held — plus two extras: you deliver the credential across a company boundary, and you can never see how it is stored or who has copies. Both facts shape rotation, below, and the delivery mechanics are covered in the partner credential lifecycle.

A Policy You Can Copy

Here is a complete, defensible password policy for a transfer service, ready to paste into your standards document and adjust. It is deliberately short; policies fail by being unread.

PASSWORD POLICY - FILE TRANSFER SERVICE

1. LENGTH. Human accounts: minimum 14 characters; passphrases of four or
   more random words are encouraged. Machine, service, and partner
   accounts: minimum 20 characters, randomly generated.
2. COMPOSITION. No required character classes. Any character is allowed,
   including spaces. Length and randomness are the requirements.
3. UNIQUENESS. Every account gets its own password, used nowhere else --
   not on other systems, not by other accounts, not by other partners.
4. SCREENING. Where supported, reject passwords found in known-breach
   lists and obvious dictionary choices at the time they are set.
5. STORAGE. Humans store passwords only in an approved password manager.
   Machine credentials live in protected configuration or a credential
   store -- never in script text, tickets, email, or spreadsheets.
6. ROTATION. Human passwords change on events only: suspected compromise,
   appearance in a breach, or exposure (spoken aloud, pasted, emailed).
   Service and partner passwords also rotate on a fixed schedule, because
   their triggering events are invisible to us.
7. LOCKOUT. Failed-attempt throttling and lockout are enabled on every
   interface that supports them (see the lockout standard).
8. NO SHARING. One account per person, job, or partner. Shared passwords
   are treated as already compromised.

Every line above traces back to an attack from the first section — that is the test any proposed rule should pass before it enters your policy. If nobody can name the attack a rule blunts, the rule is decoration.

Honest Rotation Guidance

For years, forced rotation every sixty or ninety days was the badge of a serious password policy. Then defenders started studying what it actually produced: Warehouse7! becomes Warehouse8!, and the winter-themed password reliably becomes the spring-themed one. Humans asked to re-memorize on a calendar respond with minimal, predictable increments — and attackers' tools guess exactly those increments. Worse, a password's age was never the risk; its exposure was. Mandatory rotation churned the safe passwords along with the burned ones while training everyone to choose weaker ones. Modern guidance dropped it, and this library will not pretend otherwise.

The honest rule is: rotate on events, not on birthdays. The events that matter:

• Suspicion or evidence of compromise — odd logins, a hit in your monitoring, a partner reporting trouble.
• Departure — anyone who knew or could access the credential leaves the team or the company.
• Appearance in a breach — the password, or the account holder's reused password, shows up in leaked data.
• Exposure — it was emailed, pasted into a chat, printed in a log, or spoken in a meeting. Once seen, it is spent.

Now the important exception, and it is not a loophole in the logic but a consequence of it. Event-driven rotation works only if you can see the events. For service and partner credentials, you mostly cannot. The engineer who set up the partner's side of the job leaves the partner company — nobody emails you. A contractor who once read the config file rolls off — you never knew they existed. And unattended credentials accumulate silent copies over time: in old configs, in backups, in a colleague's notes. For these accounts, a rotation schedule is a stand-in for the departure and exposure events you will never be told about. That is why the policy above rotates machine and partner credentials on a calendar while leaving human passwords event-driven. Both halves are the same principle applied to different visibility.

Machines do not memorize, so the classic argument against scheduled rotation — humans respond with predictable increments — does not apply to them: each rotation is a fresh random string at full strength. Rotation of unattended credentials must be operationally planned so jobs do not break mid-cutover; the overlap-window technique for that is described in the partner credential lifecycle.

Generating Strong Credentials

Humans are terrible random number generators — any password a person invents is drawn from the well-mapped space of things people think of. So the generation rule is simple: machines generate, humans transcribe. Three practical generators, all built in or free:

# Linux / macOS: 24 random bytes, base64-encoded (~32 characters)
openssl rand -base64 24
# example output: 8f3kQz1vNwYtR6pLm2XcAe9BsD4hUjKo

# Windows PowerShell: 24 random characters from letters and digits
-join (1..24 | ForEach-Object { [char](Get-Random -InputObject (48..57 + 65..90 + 97..122)) })
# example output: t7Kq2ZrX9mAeW3pV5nCd8LbS

# Any password manager: use its generator, set length to 20+ and
# switch OFF "require symbols" if a partner's system chokes on them

Two practical notes. First, some partner systems and older clients mishandle certain symbols in passwords (quotes, backslashes, semicolons cause quoting bugs in scripts); a long alphanumeric password sidesteps the whole class of problems at no real cost to strength — length covers it. Second, generate at the moment of issue, never in advance from a list, and never derive partner passwords from a pattern like AcmeXfer9!, BravoXfer9! — patterned credentials fall together, and one partner seeing their own password can infer the next partner's.

For human passphrases, the equivalent of a generator is random word selection — several words picked by dice or software from a large list, not a favorite quote. A lyric or motto is exactly the kind of "long" password guessing tools already contain.

Where Passwords Live

Policy usually obsesses over choosing passwords and goes quiet about storing them, which is backwards — most password disasters are storage disasters. Four rules cover the estate.

On the server, passwords should exist only as hashes, computed by the server software itself. You do not build this; you verify it — check your server's documentation for how account passwords are stored, and treat any product that can email you your own forgotten password as a red flag, because that means it kept the original.

With humans, the password manager is the approved location, full stop. Browsers' built-in managers are acceptable for low-stakes accounts; the transfer service's admin credentials belong in the real vault. Spreadsheets named accounts.xlsx, wiki pages, and email threads are where credential leaks come from years later.

With machines, the credential belongs in the tool's protected configuration or the operating system's credential store — never in the visible text of a script, where it will be copied into version control and backups forever. This deserves and has its own article: service account hygiene.

With partners, the delivery moment is the exposure moment: never send username and password together in one email. Split channels — and retire any credential that has ever traveled in cleartext. The full playbook is in the partner lifecycle article.

Enforcement and Monitoring

A policy nobody enforces is a wish. Enforcement has a technical half and an observational half.

The technical half: set whatever minimums your server software supports — minimum length where available, and above all the throttling and lockout controls, which are the mechanism that makes password guessing uneconomical regardless of user behavior. Designing thresholds that stop attackers without stranding your own partners is a craft, covered in reading auth failures and designing lockouts.

The observational half: watch the login record. Failed-attempt patterns tell you which accounts are under guessing pressure; a service account that suddenly authenticates from a new address tells you a credential has wandered. On a Windows transfer server such as Sysax Multi Server, the built-in activity logging records login attempts per account across FTP, FTPS, SFTP, and HTTPS, which gives you that visibility without extra tooling. Reviewing it routinely belongs to the wider practice of transfer logging and audit.

The Short Version, and Where to Go Next

Length is the requirement; complexity rules are theater. Humans get one strong passphrase or a password manager; machines get twenty-plus random characters they will never need to remember; every credential is unique. Rotation follows visibility: on events for humans, whose events you can see — on a schedule for service and partner credentials, whose events you cannot. Store hashes on the server, vault everything else, and let lockouts and logs enforce what paper cannot.

From here: service account hygiene takes the machine-credential thread through storage, scoping, and documentation; the partner credential lifecycle turns the rotation schedule into a working procedure with templates; and if you are deciding whether passwords are even the right method for an account, start at authentication methods compared.

Frequently Asked Questions