LPI Security Essentials common mistakes
LPI Security Essentials · Understand the traps and how to avoid them.
Treating symmetric and asymmetric encryption as interchangeable and answering that public-key cryptography is used to encrypt bulk data such as disk volumes or TLS payloads.
Candidates learn 'asymmetric is more secure' and assume it must be used everywhere, missing that RSA/ECC are computationally expensive and are used for key exchange and signatures, while AES-class ciphers handle bulk data.
What to do instead
Memorise the division of labour: asymmetric algorithms solve key distribution and non-repudiation; symmetric algorithms provide fast confidentiality. In hybrid schemes such as TLS, the asymmetric step negotiates or wraps a symmetric session key. Map every scenario question to 'what problem is being solved' before choosing the algorithm.
Confusing hashing with encryption and claiming that a password hash can be 'decrypted' or that hashing provides confidentiality.
Both transform data into unreadable output, so the surface similarity misleads. Candidates also blur the purpose of salting and key stretching.
What to do instead
Anchor on directionality: encryption is reversible with a key, hashing is one-way. Hashes give integrity and password verification, not secrecy. Salts defeat precomputed rainbow tables and ensure identical passwords yield different digests; slow algorithms (bcrypt, scrypt, Argon2) resist brute force. Practise explaining why a leaked hash database does not directly reveal passwords.
Treating a firewall as sufficient network protection and ignoring that encrypted or allowed-channel traffic (HTTPS on 443, DNS tunnelling, outbound C2) passes through unfiltered.
Firewalls are visually prominent in diagrams, so candidates equate 'port closed' with 'secure' and forget that most attacks ride permitted protocols.
What to do instead
Frame defence in depth: firewalls enforce reachability, but you also need application-layer inspection, egress filtering, IDS/IPS, and logging. For each scenario ask which port and protocol the attack uses and whether the control inspects content or only headers. Remember that allowing outbound 443 by default is itself a policy decision.
Answering that file permissions alone protect data, without considering that root, physical access, or a live boot can bypass them, and that permissions do not encrypt data at rest.
Permission bits are the first thing taught in Linux security, so candidates over-attribute protection to them and overlook threat models involving stolen disks or privileged attackers.
What to do instead
Separate access control from confidentiality at rest. Use least-privilege permissions (0600 for private keys, no world-writable files), but pair them with full-disk or per-file encryption, secure boot, and BIOS/UEFI passwords for physical threats. Always ask 'who is the adversary and what access do they already have?'
Believing that deleting a file, emptying the trash, or reformatting a partition securely erases the data.
The filesystem abstraction hides that deletion only unlinks metadata; blocks persist until overwritten. Candidates transfer everyday desktop intuition to security forensics.
What to do instead
Recall that secure deletion requires overwriting (shred, dd with random data) or cryptographic erasure, and that SSDs and wear-levelling make overwrite unreliable, so full-disk encryption plus key destruction is the robust approach. Match the erasure method to the media type in scenario questions.
Conflating authentication with authorisation and answering that a valid login means a user may perform an action.
Both are abbreviated 'auth', and everyday systems often bundle them, so candidates skip the distinction under time pressure.
What to do instead
State the definitions explicitly: authentication proves identity, authorisation decides permitted actions. Then check the question's verb: 'who are you' versus 'may you do this'. Multi-factor authentication strengthens the first and does nothing for the second; role-based access control and least privilege address the second.
Describing MFA as 'two passwords' or counting two factors of the same type, such as a password plus a security question.
Candidates memorise 'something you know, have, are' but fail to apply the rule that factors must come from different categories.
What to do instead
Test each proposed pair against the three categories. Password plus TOTP app is valid (know + have); password plus security question is not (know + know). Also note weaknesses: SMS is vulnerable to SIM swapping, and push notifications to MFA fatigue, so prefer hardware tokens or TOTP for high-value accounts.
Assuming HTTPS guarantees a trustworthy site, and ignoring certificate validation errors or the difference between transport encryption and site legitimacy.
The padlock icon is marketed as a safety signal, so candidates equate TLS with trust and forget that attackers obtain valid certificates freely.
What to do instead
Separate the two claims: TLS protects data in transit against eavesdropping and tampering; it says nothing about the operator's intent. Check the hostname, the issuing CA, and validity dates, and treat certificate warnings as stop signs. Phishing sites routinely present valid certificates, so legitimacy requires reputation and content checks.
Treating privacy as identical to security and answering that encrypting data satisfies privacy obligations.
The two fields overlap in tools, so candidates collapse them and miss privacy-specific principles such as data minimisation, purpose limitation, and consent.
What to do instead
Define the split: security protects data from unauthorised access; privacy governs whether collection and use are appropriate in the first place. Learn the core principles (minimisation, purpose limitation, storage limitation, transparency, user rights) and apply them to scenarios: encryption of data you should never have collected is still a privacy failure.
Memorising that 'antivirus catches malware' and ignoring patching, least privilege, and the limits of signature-based detection against novel or fileless threats.
Antivirus is the most familiar control, so candidates default to it and overlook that most breaches exploit unpatched software or misconfiguration.
What to do instead
Build a layered answer: patch management closes known vulnerabilities, least privilege limits blast radius, application allow-listing and behavioural detection catch fileless attacks, and backups enable recovery. For any 'best first step' question, prefer the control that removes the root cause (patching, configuration) over detection alone.