---
title: "Authentication, Authorisation and Secure Defaults"
description: "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"
canonical: https://lightmysky.com/learn/computing/authentication-authorisation-and-secure-defaults-mt_ofIiD4Bbpk
source: https://lightmysky.com/learn/computing/authentication-authorisation-and-secure-defaults-mt_ofIiD4Bbpk.md
retrieved: 2026-09-12
---

> **Agent view.** This is the Markdown twin of the page, for tools and assistants.
> When to use this site, and the call that answers each job: https://lightmysky.com/agent-instructions.md
> API description (OpenAPI 3.1): https://lightmysky.com/openapi.json · Authentication: https://lightmysky.com/auth.md
> Pricing: https://lightmysky.com/pricing.md · Catalog: https://lightmysky.com/llms.txt · Full catalog: https://lightmysky.com/llms-full.txt
> Every machine-readable file on this domain: https://lightmysky.com/.well-known/ai-catalog.json
> Ask for Markdown with `Accept: text/markdown`, a `.md` address, or `?mode=agent`.

# 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.

Subject: Computing · Area: Networks & Security · Ages 21 to 22
Page: https://lightmysky.com/learn/computing/authentication-authorisation-and-secure-defaults-mt_ofIiD4Bbpk

## Ready when they can

- 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

## Lesson: Who you are, then what you may do

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.

**Example.** 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.

**Tip.** 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.

**Recap.** Prove who, then limit what, store secrets slowly and salted, and shut rather than wave through when in doubt.

## Practice

8 questions on this page, each with its working shown.

## Needs first

- [What an Operating System Is: Privilege and System Calls](https://lightmysky.com/learn/computing/what-an-operating-system-is-privilege-and-system-calls-mt_0kMavEKxpX)
- [Hashes, Signatures and Certificates](https://lightmysky.com/learn/computing/hashes-signatures-and-certificates-mt_qLHm767U87)
- [Threat Modelling: Assets, Adversaries and Trust Boundaries](https://lightmysky.com/learn/computing/threat-modelling-assets-adversaries-and-trust-boundaries-mt_VRXTkrNFvx)