Security and Secrets
Protect credentials, distinguish cryptographic purposes, and design safer input and logging boundaries.
By the end, you’ll be able to…
- Generate secrets with secrets rather than random.
- Distinguish hashing, authentication, encryption, and password storage.
- Keep credentials outside source and ordinary diagnostic output.
01A secret needs unpredictability and a lifecycle
A secret is useful only while unauthorized parties cannot obtain or predict it. API tokens, reset links, and signing keys need a cryptographically suitable random source. Python’s random module is designed for simulation and reproducible sampling, while secrets exposes operating-system randomness for security-sensitive generation. A longer predictable string is not a replacement for an unpredictable token.
Generation is only the first step. Plan where a token is stored, which operation it authorizes, when it expires, how it is rotated, and how it is revoked after exposure. Keep example credentials visibly artificial. Do not place real tokens in source files, URLs, screenshots, committed fixtures, or exception messages. A source-control deletion does not revoke a credential that has already been copied.
02Cryptographic operations answer different questions
A cryptographic hash maps data to a digest and is useful for identifying content, but an unkeyed digest does not prove who created it. An attacker who can replace both a file and its digest can provide a matching pair. HMAC adds a shared secret key to authenticate a message. Encryption protects confidentiality and requires a suitable authenticated design, not an invented XOR loop.
Passwords need a dedicated password-hashing scheme with salts and a configurable work factor; a fast SHA-256 digest is unsuitable for storing passwords. Libraries and policy guidance for password storage evolve, so use an established implementation and current security guidance for a real authentication system. This lesson demonstrates standard-library message authentication, rather than building an authentication system or claiming a complete security design.
03Load configuration without spreading it
Environment variables can keep a credential out of a source file, but they are not automatically a secret vault. Processes, diagnostics, deployment tools, and other users with sufficient access may expose them. Use your deployment environment’s secret facility where appropriate, restrict access, and pass the minimum required credential to the component that needs it.
Validate required configuration at startup and report the missing setting name without printing its value. Avoid logging whole request headers, full environment dictionaries, or URLs containing credentials. Redaction is safer when sensitive fields are excluded by design rather than removed with a fragile regular expression after formatting. Error messages should provide operation and record context while keeping secret material out of ordinary logs.
04Validate where data changes authority
Untrusted input becomes dangerous when it changes the meaning of a powerful operation. SQL parameters separate data from query structure; subprocess argument lists avoid shell interpretation when shell=False; a path policy can prevent an upload name from selecting an arbitrary destination. Pick the boundary for the operation instead of searching for one universal sanitize function.
Do not use eval, exec, or pickle to parse untrusted data. JSON has a narrower data model, but still needs size and schema checks. Keep permissions minimal and dependencies maintained, and write regression checks for the security boundary you actually implement. These practices reduce common mistakes; a deployed product still needs review appropriate to its users, data, and exposure.
The ideas worth keeping.
- Use unpredictable tokens with rotation and revocation plans.
- Choose cryptographic tools by their purpose.
- Exclude secrets from logs and validate authority-changing inputs.
Make it yours.
Type and test your code right here in the interactive workspace. Run your solution, check the output, and compare with the worked guide when ready.
Exclude secret fields
Create an audit_record mapping with only event, user_id, and success. Do not copy token or password even when input includes them.
Explore a worked solution
def audit_record(details): return { 'event': details['event'], 'user_id': details['user_id'], 'success': bool(details['success']), }record = audit_record({'event': 'login', 'user_id': 7, 'success': True, 'token': 'example', 'password': 'example'})assert set(record) == {'event', 'user_id', 'success'}An explicit allowlist avoids accidentally logging a new sensitive field when an upstream input dictionary grows.
Verify a signed fixture
Implement verify(key, message, supplied_tag) using HMAC SHA-256 and compare_digest. Verify both an unchanged and a modified message.
Explore a worked solution
import hmacdef verify(key, message, supplied_tag): expected = hmac.digest(key, message, 'sha256') return hmac.compare_digest(expected, supplied_tag)key, message = b'demo-key', b'record:12'tag = hmac.digest(key, message, 'sha256')assert verify(key, message, tag)assert not verify(key, b'record:13', tag)The key authenticates the bytes, and compare_digest avoids ordinary early-exit equality behavior. Secure key storage, replay prevention, and message framing remain separate requirements.
What stayed with you?
Check the ideas while they’re fresh. Your answers stay in this page and feedback appears as you go.
Exclude secret fields
Create an audit_record mapping with only event, user_id, and success. Do not copy token or password even when input includes them.
[Process exited with code 0 - No output]
Keep exploring.
The official references behind this chapter, when you want a second angle or the full details.
One chapter closer.
Reading is a start. Trying it yourself makes the connection.