Credentials Belong to macOS

"The safest password is the one your app never has. You can't leak a secret you refused to hold."

The Temptation to Store the Password

Reconnecting to a share is smoother if the app just remembers the username and password. So the tempting design is to stash them somewhere — in the saved URL (smb://user:pass@host), in the app's database, in a config file. Every one of those is a leak waiting to happen: the URL ends up in a log, the database gets backed up somewhere readable, the config file gets committed to git. A stored secret is a secret with many exits.

Waygate Holds No Secret

Waygate's design removes the whole risk by never holding the secret. It has no credential store. The username and password are owned entirely by macOS's connect UI and Keychain — the system prompts, the system stores, the system supplies them at mount time. Waygate never puts a credential in a URL, its SQLite, a log line, or anything that could reach git. When a share needs connecting, Waygate triggers the system flow and steps back.

Not Storing Is the Strongest Protection

This is a general security truth worth internalizing: the most reliable way to never leak a secret is to never possess it. Encrypting a stored password is better than plaintext, but it still means your app holds the key, the ciphertext, and the responsibility. Delegating to Keychain means the secret was never yours to lose. Waygate chooses delegation every time — the file manager's job is to browse and mutate files, not to be a second password manager.

Credentials live only in macOS and Keychain; Waygate persists none. No username or password ever enters a URL, the database, a log, or git. Waygate triggers the system connect flow and lets macOS own the secret — because not holding a credential is the most reliable way to never leak one.

The family shares this instinct. Across the cwk siblings, the rule is the same: secrets stay in the OS Keychain, never in a repo, never in a log. Even in these very quests, an internal reference is described conceptually and never as a real hostname, IP, or credential — because the surfaces Dad builds are a trust boundary, and a file manager that hoards passwords would betray exactly the trust it exists to earn.

Code

Wrong vs right: who holds the password·swift

// WRONG -- the credential is now in a URL string that leaks into logs,
// history, crash reports, and anywhere the URL is serialized:
let url = URL(string: "smb://alice:hunter2@fileserver.local/projects")!   // LEAK
saveToDatabase(url)                                                       // LEAK^2

// RIGHT -- store only the sanitized address; ask macOS to connect.
// macOS prompts for and stores the credential in Keychain; Waygate never sees it:
let endpoint = SavedNetworkLocation(scheme: "smb", host: "fileserver.local",
                                    share: "projects", displayName: "Projects")
NSWorkspace.shared.open(endpoint.connectURL)   // system connect flow owns the secret
// Waygate's database stores `endpoint`. There is no password anywhere in it.

Exercise

Audit an app or script you've written that connects to something with a password. Find where the secret lives — a config file, an env var, a URL, a hardcoded string. Trace every place that value could end up (logs, backups, git, crash reports). Then redesign it so the app never holds the secret at all. What owns it instead?

Hint

Follow the secret's copies: a config file gets backed up, an env var shows in process listings and crash dumps, a URL lands in logs. The redesign delegates to a system credential store (Keychain, a secrets manager) that prompts and supplies the secret at use time, so your code only ever holds a reference, never the value. The strongest audit result is 'the secret was never in my process to leak.'

Credentials Belong to macOS

The Temptation to Store the Password

Waygate Holds No Secret

Not Storing Is the Strongest Protection

Code

External links

Exercise

Progress

Comments 0