Authentication, Authorisation and Secure Defaults
Proving who someone is and deciding what they may do are two questions, and confusing them is a common source of holes. Storing credentials with a slow hash, giving each part the least access it needs, and failing closed are the defaults that hold up when something else goes wrong.
What a learner can do afterwards
- Separate an authentication decision from an authorisation decision in a stated design
- Say why passwords are stored with a deliberately slow hash and a per-user salt
- Apply least privilege to a service and name what it no longer needs
1 · Read
Two questions guard every system, and mixing them opens holes. Authentication asks who you are, checking a password or fingerprint. Authorisation asks what you may do now that you are known, like Sam may read a file but not delete it.
Maya proves she is Maya with her password, which is authentication. The list then says she may read the rota but not edit pay, which is authorisation. If the login server is down, both answers stay no until it recovers.
Passwords rest as hashes made with a deliberately slow method plus a per-user salt, a random extra mixed in. Stealing the list then gives no passwords, and each guess costs costly time. Give every part the least access it needs, and fail closed when unsure.
To apply least privilege, list what a service touches today and strip what it never needs. Name each removal aloud, like the rota reader no longer needs pay files or the master key.
Prove who, then limit what, store secrets slowly and salted, and shut rather than wave through when in doubt.
2 · Watch
Take it off screen
Where it sits
Learn first
This opens up
Nothing builds on it yet.
8 questions wait behind this lesson, each with its answer explained. Every answer feeds the sky: stars light as they are learned, and dim when it is time to come back.