skip to content

What is the difference between the master password and a server password, and how do they relate cryptographically?

level: middleimportance: should knowfreq 35%

answer

  1. one master, many server pwds
  2. master = key, server = secret
  3. rotate master => re-encrypt all
  4. master wrapped with built-in key
  5. obfuscation boundary

basics

~10 s

The master password is the single key, stored encrypted in settings-security.xml. Server passwords are the actual repo secrets in settings.xml, each encrypted using the master. The master decrypts every server password.

solid answer

~40 s

Think of two layers. The master password is a single secret stored (encrypted with a fixed internal key) inside `~/.m2/settings-security.xml`. Every encrypted `<server><password>` in settings.xml is encrypted with that master. So at build time Maven first decrypts the master, then uses it to decrypt each server password. The relationship is one-to-many: one master unlocks all server entries. Rotating the master means re-encrypting every server password with the new master (the old ciphertexts no longer decrypt). Because the master itself lives on the same machine and is wrapped only with a built-in key, anyone with local file access can recover everything — so the boundary it protects is accidental disclosure, not local compromise.

go deeper

for a junior

Knows master is in settings-security.xml and server passwords in settings.xml.

for a middle

Explains the one master encrypts many server passwords relationship.

for a senior

Reasons about rotation cost and the obfuscation-vs-protection boundary.

for a principal

Sets policy: master files machine-local, secrets injected, rotation runbooks.

## Two roles, one chain - **Master password** — one per machine/user. Stored in `~/.m2/settings-security.xml` inside `<settingsSecurity><master>`. It is itself wrapped (Maven encrypts it with a built-in, well-known key), which is why publishing settings-security.xml is unsafe. - **Server password** — the real credential for a specific repository. Stored in `~/.m2/settings.xml` inside `<server><password>`. It is encrypted **with the master**. ## The decryption chain at build time 1. Maven loads settings-security.xml and decrypts the master. 2. For each `<server>` with an `{...}` password, it uses the master to decrypt the real password. 3. It applies that password to authenticate HTTP(S) to the matching repository. ## One-to-many and rotation One master encrypts many server passwords. If you change the master, you must re-run `mvn --encrypt-password` for every server, because the old `{...}` tokens were tied to the previous master and will fail to decrypt. ## Why this is obfuscation, not strong security The master is wrapped with a fixed internal key shipped in Maven, so the master file is essentially decodable by anyone who has it. The encryption stops casual plaintext exposure (e.g. a screen-share or a stray backup), but it does not protect against an attacker with local read access. For real protection, inject secrets at runtime (CI secret store, environment variables referenced from settings, or an external vault) and keep settings-security.xml machine-local and unshared. ```xml <!-- settings-security.xml: the master (the key) --> <settingsSecurity> <master>{master-token}</master> </settingsSecurity> ```

  • What happens to existing server passwords if you change the master?
    They stop decrypting; you must re-encrypt each server password with the new master.
  • Why is settings-security.xml unsafe to share even though the master is 'encrypted'?
    It is wrapped with a fixed internal Maven key, so anyone who has the file can recover the master and then every server password.

saying these in an interview costs you the question

  • Saying the master and server passwords are interchangeable
  • Believing rotating the master leaves existing server tokens valid
  • Treating settings-security.xml as safe to commit because it's 'encrypted'

context

resolving links…