skip to content

What can a store do with a downstream database account that a file holding the same password structurally cannot?

level: middleimportance: should knowfreq 40%

answer

  1. A file is a container, not an authority
  2. Static is shared, generated is per consumer
  3. Attribution and local withdrawal follow
  4. Rights stop being everyone's union
  5. The store now holds account-creating authority

basics

~20 s

Make the credential instead of holding it. Given authority on the downstream system, a store can create a distinct account per consumer at request time, so each has its own identity, its own rights and a withdrawal that touches nobody else.

solid answer

~40 s

A file contains only what a person typed into it, which makes the value **static**: one password, shared by every consumer, valid until somebody changes it everywhere at once. That single property is what makes use unattributable — every consumer authenticates as the same account — and what makes withdrawal estate-wide. A store that has been given authority on the downstream system can **generate** instead: at request time it creates an account for that one consumer, with only the rights that consumer needs, and hands back credentials nobody else holds. A leak is then traceable to a consumer, withdrawal is deleting one account, and no long-lived shared password exists to be copied. The cost moves up a level: the store now holds an account-creating credential on that system.

code

pseudocode · 17 lines
pseudocode
// static: the file hands the same value to everyone
readFromFile("reporting-db-password")
    -> { user: "app", password: "<typed once, shared by 12 consumers>" }

// generated: the store creates one account for this consumer
onRequest(consumer, name = "reporting-db"):
    account = downstream.createAccount(
        name  = "svc-" + consumer.id,
        rights = grantFor(consumer).rights)   // narrower than the union
    record(readBy = consumer.id, name = name, at = now)
    return { user: account.name,
             password: account.password,
             expiresAt: now + grantFor(consumer).maxLife }

// withdrawal, per consumer, touching nobody else
onWithdraw(consumer):
    downstream.dropAccount("svc-" + consumer.id)

go deeper

for a junior

Remember that a file can only hold a value somebody typed in, and that everyone reading the file authenticates as the same account.

for a middle

Explain the property chain in the right direction: generated means per consumer, which is what makes use attributable and withdrawal local; static means shared, which makes both estate-wide.

for a senior

Say where the risk moved. The store's authority to create accounts is now the most powerful credential in the arrangement, and orphaned accounts are the new cleanup problem.

for a principal

Set expectations for a mixed estate: generation applies only where the downstream system cooperates, so plan for both kinds rather than a policy that assumes one.

## Static and generated are different objects The distinction is not about strength or length; it is about **where the value came from** and therefore how many parties hold it. - A **static** credential is minted once by a person and then stored. Every consumer that needs it reads the same value. Its properties follow: use is unattributable because all consumers authenticate as one account; withdrawal is estate-wide because the account being withdrawn is everyone's; and the value's age is whatever the last manual change made it. - A **generated** credential is created on request by the store, per consumer. Its properties follow the other way: use is attributable to the consumer that asked, withdrawal is local because deleting one account leaves the others working, and the rights can be narrowed per consumer instead of being the union of everything anyone needs. An encrypted file can only ever hold the first kind. It is a container; it has no authority anywhere and cannot cause anything to exist. That is the structural limit in the question, and it does not go away with better encryption, better key handling or a better review process around edits. ## What the store needs in order to generate For a store to create a downstream account, three things have to be true: 1. **The downstream system must support creating accounts programmatically**, with rights attached at creation. 2. **The store must hold a credential on that system with authority to create and drop accounts** — and that credential is now the most powerful thing in the arrangement. 3. **The consumer must tolerate a credential that differs per instance and changes over time**, which means reading it at start-up rather than baking it into an image or a rendered file. Store designs differ on whether they do this at all: some mint downstream credentials, others only hold what you gave them. It is a capability to confirm, not to assume. ## What actually improves | Property | One shared password in a file | An account minted per consumer | |---|---|---| | Who authenticated? | Unattributable — one account | The consumer that asked for it | | Withdrawing one consumer | Change it for everybody | Drop that one account | | Rights | The union everyone needs | Only what that consumer needs | | A copy in a log or a note | Valid for all consumers | Valid for one, and traceable | | Replacing the value | A coordinated change | A new account, on request | The entry that matters most in practice is the third: a shared password's rights are always the **union** of every consumer's needs, because one value serves them all. Per-consumer accounts are the mechanism that makes least privilege expressible at all against a system that only understands accounts. ## Where the risk went Generation does not remove risk, it **moves it up a level**. Before, the worst thing in the file was one account's password. After, the worst thing is the store's own authority to create accounts on that system — a compromise of which is not one account but the ability to make any number of them, with any rights. Three consequences follow, and a good answer names them: - The store's own access to the downstream system deserves narrower rights than people usually give it: create and drop accounts of a bounded shape, not full administration. - The downstream system must tolerate the account count, and something must clean up accounts whose consumer is gone, or the estate accumulates live accounts nobody is watching. - Creating a credential is not the same as withdrawing one: an account minted and forgotten is exactly the static credential you were trying to get away from, with worse inventory. ## The honest limit Not everything can be generated. Plenty of credentials come from systems that will only ever give you one value typed into a form, and for those the store is back to holding what you gave it — which is still worth doing for the granularity, the record and the per-holder withdrawal, but the generation argument does not apply. A candidate who claims a store makes every credential short-lived and per-consumer has over-claimed; the correct statement is that it makes that possible **where the downstream system cooperates**, and that a mixed estate of generated and static credentials is the normal outcome.

  • Does generating credentials remove risk, or move it?
    It moves it up a level. The worst thing in the old arrangement was one account's password; now it is the store's authority to create accounts on that system, which is strictly more powerful. That authority should be narrowed to creating and dropping accounts of a bounded shape, and it becomes the thing worth watching most closely.
  • The downstream system can only be given one password typed into a form. What is left of the argument?
    Everything except generation. The store still gives rights per name rather than one file-wide key, a record of each read, and withdrawal of one holder without re-keying the rest. A realistic estate ends up mixed — some credentials minted per consumer, many still static — and saying so is more credible than claiming the store makes them all short-lived.
  • What new failure does per-consumer generation introduce downstream?
    Accumulation. Accounts are created per consumer and per instance, so something must remove the ones whose consumer is gone. An account minted and forgotten is a static credential again, with worse inventory than the file had, because nobody typed it and nobody owns it.

saying these in an interview costs you the question

  • Says a store makes every credential short-lived by itself
  • Thinks generation is just automated rotation of one shared password
  • Ignores that the store now holds account-creating authority
  • Attributes attribution and local withdrawal to the static value
  • Assumes every downstream system can mint accounts on request