Identity, Secrets & Encryption
Three building blocks underpin most software security: knowing who a user is and what they're allowed to do, keeping secrets like passwords and keys safe, and encrypting data so that intercepting it is useless. A developer touches all three constantly, so the concepts are worth getting clear.
None of these are exotic — they're the everyday plumbing of keeping an application and its users safe.
A building gives the picture: an ID badge proves who you are (authentication), the badge's access level decides which doors open for you (authorization), and a safe holds the master keys (secrets). Three different jobs, all needed.
AuthN vs AuthZ
Two similar words, two different jobs. Authentication (authN) answers "who are you?" — proving identity, usually with a login. Authorization (authZ) answers "what are you allowed to do?" — deciding which actions and data your identity may access. You authenticate once (log in), then the system authorizes each thing you try to do. Mixing them up is a classic source of security holes, so keep them straight: who you are, versus what you can do.
Secrets Management
Software needs secrets — passwords, API keys, tokens — to talk to databases and other services. The cardinal rule is to keep them out of the code and out of version control, where they'd leak. Instead, secrets live in a dedicated secrets vault or are supplied through the environment (the twelve-factor "config in the environment" idea). A secret hard-coded into the source is a breach waiting to happen, because anyone who sees the code sees the keys.
Encryption
Encryption scrambles data so that without the key it's unreadable. You encrypt data in transit (as it travels the network — this is what HTTPS does) and at rest (while stored), so that intercepting or stealing it gives an attacker useless gibberish. Encryption is reversible by design: with the right key, the data comes back. It's the reason a stolen database or a tapped connection doesn't automatically mean exposed data.
Hashing Passwords
Passwords get special treatment: you never store them readably, even encrypted. Instead you store a hash — the result of a one-way function that turns the password into a fixed string that can't be reversed back. When a user logs in, you hash what they typed and compare hashes. So even if the database is stolen, the actual passwords aren't in it. This is the key difference from encryption: encryption is reversible (you get the data back); password hashing is deliberately one-way (you can't).
Cadence uses all three. It authenticates each user at login, then authorizes every action so a user can only touch their own habits, never anyone else's. Its database password lives in a secrets vault, never in the code. Everything travels over HTTPS (encryption in transit), and user passwords are stored only as one-way hashes. None of it is exotic — it's just the standard, careful plumbing of a trustworthy app.
- "Authentication and authorization are the same." AuthN is who you are; authZ is what you're allowed to do. You prove identity once, then get authorized for each action — distinct steps.
- "Secrets in the code are fine if the repo is private." Private repos leak, get cloned, and outlive their privacy. Secrets belong in a vault or the environment, never committed alongside the code.
- "Encryption and hashing are the same thing." Encryption is reversible (you can get the data back with a key); password hashing is deliberately one-way and can't be reversed — that's exactly why it's used for passwords.
- AuthN, authZ, secrets, and encryption are the security concepts a developer touches daily — getting them wrong causes the worst breaches.
- The distinction between reversible encryption and one-way hashing is a genuinely important idea that protects passwords even when a database is stolen.
- Knowing secrets belong in a vault, not the code, prevents one of the most common and damaging real-world security mistakes.
Knowledge Check
What is the difference between authentication and authorization?
- Authentication is who you are; authorization is what you're allowed to do
- They are two different words that both mean exactly the same thing
- Authentication encrypts all the data while authorization later decrypts it again
- Authentication is what you can do; authorization is who you are
Where should an application's secrets (like a database password) be kept?
- In a dedicated secrets vault or supplied through the environment
- Hard-coded right into the source code so they are easy to find
- Committed into version control, as long as the repository is private
- Displayed on the screen so that users can see and verify them
What does encryption do?
- Scrambles data so it's unreadable without the key, and reversible with it
- Permanently destroys all of the data so that no one can ever read it again
- Makes the finished program run noticeably faster for all its users
- Decides which users are allowed to log into the application
Why are passwords stored as one-way hashes instead of being encrypted?
- A hash can't be reversed, so a stolen database doesn't expose passwords
- Because hashing makes the login process run far faster than usual
- Because hashed passwords always take up far less space than encrypted ones
- Because using encryption on passwords is actually illegal in most countries
You got correct