08 — Security Foundations — Hashing, PKI, OWASP, and Auth

"Is this secure?" was the question I kept asking, and it was unanswerable because security isn't one thing. The model that untangled the cluster: security is a stack of layered concerns — integrity, identity, access, application — and each technique defends a different layer [1]. I used to mash "security" into one fuzzy thing; treating it as layers let me stop asking "is this secure" (unanswerable) and start asking "which layer does this threat live at, and what defends it" (answerable).

The roadmap frames security as a broad field of measures and practices that protect information, systems, and networks from unauthorized access, damage, or theft [1]. The four nodes are the architect's working vocabulary across those measures.

Integrity: hashing algorithms

At the bottom layer is integrity — can I tell whether data (or a password) has been changed or guessed? Hashing algorithms generate a unique fixed-size value for a given input, and that hash is used to verify data integrity, store passwords safely, and generate unique identifiers [2]. The properties that matter:

• Deterministic — same input always produces the same hash.
• One-way — you can't reverse a hash back to its input.
• Avalanche — a one-bit change in input drastically changes the hash.

For passwords, the hash is what's stored — never the plaintext password — and verification works by re-hashing the input at login and comparing. Modern choices are deliberately _slow_ (bcrypt, scrypt, Argon2) to resist brute force; fast hashes like MD5 and SHA-1 are fine for file-integrity checks but wrong for passwords because attackers can guess billions per second [2].

Identity: PKI

The next layer up is identity at the wire level — how do two parties prove who they are to each other? That's a public key infrastructure (PKI): a set of roles, policies, hardware, software, and procedures to create, manage, distribute, use, store, and revoke digital certificates and public-key encryption [3]. PKI is the machinery behind the padlock icon in your browser — the certificate authority vouches that a public key really belongs to the named server, enabling TLS to work [3].

The way of thinking: PKI solves the _trust_ problem that public-key cryptography alone can't. Two parties can encrypt to each other's public keys, but without a trusted authority certifying those keys, there's no way to know the key belongs to whom it claims. PKI is that trusted authority layer, and it's required for anything where simple passwords are inadequate — e-commerce, banking, confidential email [3].

Access: authentication and authorization

The next layer is access — who are you, and what are you allowed to do? That splits into two distinct concerns [4]:

• Authentication (AuthN) — verifying _who_ a user is.
• Authorization (AuthZ) — deciding _what_ an authenticated user is allowed to do.

Common strategies and where they fit:

• Session-based — server stores session state, browser holds a session ID cookie. The classic web model.
• Tokens (JWT) — a signed token carries claims (user id, roles, expiry) and is verified by a signature, so the server can be stateless about sessions [4].
• OAuth 2.0 / OIDC — protocols for delegated access, letting one service access another on a user's behalf without sharing the user's password [4]. OIDC adds an identity layer on top of OAuth's authorization layer.
• SAML — an XML-based protocol common in enterprise single sign-on [4].

The choice affects both security and how easily the system integrates with other services [4]. A single-page app talking to its own backend might use JWT; a third-party app accessing a user's data on another service needs OAuth; an enterprise rolling out SSO across many apps reaches for SAML or OIDC.

Application: OWASP

The top layer is application-level vulnerabilities — the bugs the code itself introduces. OWASP (Open Web Application Security Project) is the community that produces freely-available articles, methodologies, tools, and technologies in web-application security, best known for the OWASP Top 10 — a periodically updated list of the most critical web application security risks [5]. Injection, broken authentication, sensitive data exposure, broken access control — these are the recurring categories, and the Top 10 is the checklist an architect runs when evaluating a design.

OWASP's value is that it turns "be secure" into a concrete list of known failure modes to defend against, with community-maintained cheat sheets for each [5]. An architect who hasn't internalized the Top 10 will re-invent its vulnerabilities by accident.

How I use this

I walk threats layer by layer: integrity (are passwords hashed with a slow algorithm?), identity (is TLS/PKI in place and are certificates managed?), access (are AuthN and AuthZ separated, and is the right protocol chosen for the integration?), application (does the design survive a run through the OWASP Top 10?). Asking "is it secure" never produces an answer; asking "which layer is weakest" almost always does.

References

[1] "Security," roadmap.sh — Software Architect. [Online]. Available: https://roadmap.sh/software-architect/security

[2] Codecademy, "What is Hashing?," [Online]. Available: https://www.codecademy.com/resources/blog/what-is-hashing/

[3] "Public key infrastructure," Wikipedia. [Online]. Available: https://en.wikipedia.org/wiki/Public_key_infrastructure

[4] "Auth Strategies," roadmap.sh — Software Architect. [Online]. Available: https://roadmap.sh/software-architect/auth-strategies

[5] "OWASP," Wikipedia. [Online]. Available: https://en.wikipedia.org/wiki/OWASP