diff --git a/tech-naming.md b/tech-naming.md new file mode 100644 index 0000000..a8531bd --- /dev/null +++ b/tech-naming.md @@ -0,0 +1,22 @@ +--- +title: how to choose a name (in tech) +slug: tech-naming +date: 2023-03-31 +--- + +# how to choose a name (in tech) +![](https://i.imgur.com/IxY4iks.jpg) + +tl;dr: *naming a thing well, is an opportunity to help a thing succeed. naming a thing anything less than well, is like cursing a thing.* + +in short, make your name distinct, make it simple, make it concise. + + +## distinct +a good name makes it easy to distinguish between a thing and the things it is similar to. a common misconception in tech is that things should be named in a way that highlights the things it is similar to. this is unfortunate because what it actually does is create confusion between similar things. names are chosen once by a few people. the confusion they can cause is experienced many times by many people. + +## simple +names should be easy to spell and to pronounce based on their spelling. trust me. my surname is thijssen. i can count on my fingers the people in my life who have known how to say my name after seeing it in writing or spell it after hearing it. many of them are people i am related to. easy to spell and pronounce is infinitely preferable in a multicultural setting. + +## concise +in tech, the name of a thing gets concatenated with other things. if you name your thing *the-thing-that-does-this-other-thing*, it gets really unwieldy the first time someone concatenates it with *another-thing-that-does-another-thing*. if possible, use single barelled names for anything that might get concatenated with another thing. if you don't want to concern yourself with things that might happen, just assume they will and stick with single barelling for everything. diff --git a/what-is-a-secret.md b/what-is-a-secret.md new file mode 100644 index 0000000..e301c6a --- /dev/null +++ b/what-is-a-secret.md @@ -0,0 +1,48 @@ +--- +title: what is a secret? +slug: what-is-a-secret +date: 2023-03-08 +--- + +# 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.