what is a secret?

what is not a secret?

what should organisations protect?

what should be public?

only actual, real secrets should be protected or encrypted. locking down more than your secrets, makes you weaker. when things that aren't secrets are locked down, people who need access to non-secrets, end up getting access to actual secrets, because you locked down all the non-secrets, along with the actual secrets.

keeping things that seem sensitive but are not actual secrets in the public domain, ie: in a public github or gitlab repository, has some benefits:

• authors are forced to think about what is and isn't a secret.
• authors are forced to think about the quality of their contribution, in the context of the possibility of public scrutiny.
• creators of actual secrets are forced to think about the resource they want to protect. it's not uncommon for a developer under time constraints, to create a set of credentials in order to access a resource or system and then grant that account more access privileges than it actually requires. knowing that a large part of the configuration for accessing that resource will be in the public domain, is a motivator for conscientious developers to think carefully about their implementations. ie:
  • should this database user have read-only or read-write access?
  • should the scope of that access be limited to specific tables or views?
  • since all my secure resource interaction logic is public, am i confident in the lockdown mechanism afforded by the actual secret, or am i relying on an attackers ignorance of my infra configuration, in order to protect that infra?
• accidentally leaking a secret, by publishing it to a public repository, or otherwise, forces an org to think about their secret rotation strategy and cements the concept of thinking about secrets carefully, into the mind of the leak author. it will happen and it can still be a good thing.

examples of thoughtlessly locking down non-secrets or relying on a limited audience to your secrets

• your organisation uses private repositories to manage code. since the repos are private, your members leave configuration files containing credentials checked-in to the private repositories. not only does this create multiple sources of truth as to what credentials might be valid for disparate secured systems, it means that anyone who needs to read or write code, also gets access to credentials they don't really need. managing rotations of credentials after they've been exposed to an audience that no longer needs access to them, means that credentials need to be updated in all the repositories that include them. this is a rapidly escalating vortex of confusion and exposure surfaces.
• the hostnames, ip addresses and access credentials of your infrastructure is known only by your infra team and their internal documentation system. you rely on the limited audience of that configuration logic to secure your infra. when a member of your infra team has their personal store of that knowledge breached by an attacker, your infra is exposed. it was always flawed by the reliance on obfuscation or limited access.

examples of actual secrets and non-secrets

• the password or token element of a credential pair is an actual secret. only the person identified by the complimentary username or account identifier element of the credential pair should know the password or token element. the username or account identifier element of a credential pair is a non-secret. many people may need to know that an account exists, is enabled, belongs to specific entity and has access to a secured system. those who need to know this, don't need to know the account holder's secret or have accesss to the complete credential or the systems it protects.
• the credential aspect of a database connection string is an actual secret. the username(s), host name(s), port number(s), database(s) and table(s) identified by the rest of the string are not secrets and can be useful to a wider audience than the credential holder, for example in debugging connection issues or infrastructure changes.
• in most cases identifiers like usernames, host names, port numbers, etc... are non-secrets. exceptions might include scenarios where brute-force and/or denial-of-service (dos) attacks are common. it is a mistake to treat these as secrets in environments where those sorts of attacks do not occur, because the audience who requires access to these identifiers, often does not need access to the complete credentials these identifiers refer to. any time the audience of a secret is widened, the frequency of that secret's credential rotation must be shortened due to audience disengagement.

who should know a secret?

a secret should only be known by its author. the moment it is shared, it is redundant and presents an attack surface. since it is only possible to mitigte against the risks one knows about.

if i am the only person who knows a secret and that secret is compromised, i know that i am responsible for the leak. such assurance is not possible when two or more people know the same secret.

if someone's access to a resource expires, because their role changes or otherwise, only that person's access to the resource, should be cancelled.

if two people (or two applications) require access to a resource, both should author their own set of credentials and keep those credentials to themself. access by one is not reliant on the others ability to keep the secret from being compromised and cancelled.

it should be obvious to an auditor which individual entities have accessed a resource. this is only possible if each entity has used their own, unique credentials.

a shared secret is not a secret.