Security Fundamentals — FAQ
Is encryption the same thing as hashing? People use the words almost interchangeably.
No, and mixing them up matters in practice. Encryption is reversible — anyone with the right key can decrypt ciphertext back into the original plaintext, which is exactly what you want for data you need to read again later (files, database columns, network traffic). Hashing is a one-way function — there's no key that turns a hash back into the original input, which is exactly why passwords should be hashed (bcrypt, argon2), never encrypted: you never actually need to recover the original password, only verify that a submitted password produces the same hash. Encrypting a password instead of hashing it is a real, specific mistake — it means anyone who gets the decryption key (or compromises the system holding it) can recover every plaintext password at once, which hashing structurally prevents.
Why do people say "never store passwords in plaintext," but then also say bcrypt is slow — isn't slow bad?
Slow is deliberately the point for password hashing specifically, which is the opposite of what you want from most other hash use cases (integrity checking, for instance, wants a fast hash like SHA-256). Bcrypt and argon2 are intentionally designed to be computationally expensive so that an attacker who steals a database of hashes can't brute-force millions of password guesses per second against them — the same slowness that feels like overhead for one legitimate login attempt (a few hundred milliseconds) becomes a massive practical barrier when multiplied across billions of guesses. Using a fast hash like plain SHA-256 for passwords is a real, specific mistake for exactly this reason — it's technically "hashing," but it doesn't provide the brute-force resistance that password storage actually needs.
What's the real difference between a firewall and a WAF?
A traditional (network) firewall makes allow/block decisions based on IP address, port, and protocol — it doesn't understand the content of allowed traffic. A WAF (Web Application Firewall) specifically inspects HTTP/HTTPS traffic content for application-layer attack patterns (SQL injection strings, XSS payloads) that a regular firewall would let straight through, since that traffic is typically already allowed on port 443. They're complementary layers in this course's own Defense in Depth model, not substitutes — a firewall controls what can reach a service at all; a WAF inspects what's actually inside the traffic that does reach it.
If MFA is so much stronger than a password alone, why do accounts still get compromised with MFA enabled?
A few genuinely common ways MFA gets defeated in practice, worth knowing specifically rather than assuming MFA is an absolute guarantee: MFA fatigue/push-bombing (an attacker who already has the password repeatedly triggers push notifications until the user approves one out of annoyance or confusion), SIM swapping (compromising SMS-based MFA by taking over the victim's phone number at the carrier level — one of several reasons SMS is considered the weakest MFA factor), and session token theft (stealing an already-authenticated session cookie/token via malware or a phishing proxy, which bypasses the MFA challenge entirely since it happened after authentication succeeded). None of these mean MFA isn't worth using — it's still a dramatic improvement over password-alone — but "MFA enabled" isn't the same claim as "unhackable," and knowing the actual bypass patterns is what lets you pick stronger factor types (hardware security keys resist push-bombing and SIM-swapping in ways SMS/push notifications don't) where it matters most.
Why does Zero Trust say "never trust the network," when I've already got a firewall protecting the network perimeter?
Because the traditional model's core assumption — "anything inside the network perimeter is trusted" — breaks down the moment any single internal system is compromised (a phished laptop, a vulnerable internal service), since that attacker is now "inside" and every other internal system trusts them by the traditional model's own logic. Zero Trust doesn't argue firewalls are useless — perimeter controls are still one layer — it argues that internal network location shouldn't be treated as proof of trustworthiness on its own, and every request should be authenticated and authorized regardless of whether it originated from "inside" or "outside." This is why Zero Trust architectures lean heavily on things like mTLS between internal services and continuous (not just at-login) authorization checks — the goal is that a compromised internal system gains as little as possible just from being on the internal network.
Is "the cloud" inherently less secure than running your own servers?
Not inherently — but the practical failure mode is different, and worth understanding specifically rather than assuming either direction is automatically true. Cloud providers (AWS, Azure, GCP) operate under a shared responsibility model: the provider secures the underlying infrastructure (physical security, hypervisor, network hardware), while the customer is responsible for how they configure what they run on top of it (IAM policies, security group rules, S3 bucket permissions, patching their own instances). The large majority of real cloud security incidents trace back to customer-side misconfiguration (public S3 buckets, overly permissive IAM roles, security groups open to 0.0.0.0/0) rather than a failure of the underlying cloud infrastructure itself — which is exactly why this course's own material lists those specific misconfigurations as the most common cause of cloud breaches, not "the cloud" as a category.
What's actually different between symmetric and asymmetric encryption, in terms of when you'd pick one over the other — not just the textbook definition?
Symmetric encryption (AES) is fast and efficient for large amounts of data, but requires both parties to already share the same secret key — which creates a real chicken-and-egg problem: how do you securely give someone the key in the first place, especially over a network you don't fully trust? Asymmetric encryption (RSA, ECC) solves exactly that problem (a public key can be shared openly; only the matching private key can decrypt), but is computationally much slower for large data volumes. This is why TLS uses both, not one or the other: the asymmetric handshake exists specifically to securely exchange a symmetric session key, and then all the actual bulk data transfer uses fast symmetric encryption with that exchanged key — each algorithm type is doing the part it's actually good at.
Why does everyone say "never roll your own crypto" — isn't AES just a known, documented algorithm anyone can implement?
The algorithm being public and well-documented is exactly the easy part to get right; the actual danger is almost always in the surrounding implementation details that don't show up in a textbook description — nonce/IV reuse (this course's own material explicitly flags "never reuse" for AES-GCM's nonce, and reusing it can catastrophically break the encryption's guarantees), timing side-channels in comparison logic, incorrect padding handling, and key management mistakes. Well-vetted cryptographic libraries have had these specific failure modes found and fixed by the broader security community over years of scrutiny — a from-scratch implementation starts from zero on all of that hard-won, non-obvious knowledge, which is the actual reason the advice exists, not that AES itself is secret or hard to look up.
Is a vulnerability scanner enough to know an application is secure?
No — a scanner (SAST/DAST/dependency scanning) catches known patterns and known-CVE dependencies well, but it fundamentally can't reason about business logic flaws specific to your application (a checkout flow that lets a discount be applied twice through a specific sequence of requests, an authorization check that's present on the UI but missing on the underlying API endpoint). This is exactly why this course's own DevSecOps material treats SAST/DAST/SCA as one layer in a pipeline rather than a complete answer — scanners are a necessary, automatable floor, and manual security review or penetration testing exists specifically to catch the logic-level issues that pattern-matching tools structurally can't.
Does having a security certification (Security+, CC) mean someone can actually do security work, or is it just a filter?
Realistically, both things are true at once, and it's worth holding them separately rather than picking one. These certifications validate foundational vocabulary and conceptual understanding — genuinely useful, and a real signal that someone has put in structured study time — but they're not a substitute for hands-on experience with real systems, real logs, and real ambiguity that a multiple-choice exam can't fully replicate. This is exactly why entry-level roles often pair a certification requirement with "or equivalent hands-on experience," and why this course's own material for related technologies repeatedly points toward home-lab practice and platforms like TryHackMe alongside certification study, rather than treating the cert alone as sufficient preparation for the job.