Securing Devices

A device is any computer - a server, a personal laptop, a smartphone, or an embedded computer 嵌入式计算机 built into a machine. Everyday devices with embedded computers are called Internet of Things (IoT) 物联网 devices, and they run everything from water pumps to washing machines.

The four classes of device, and why the class matters

That last row is the reason embedded and IoT devices appear so often in attack scenarios: the constraints that make them cheap are the same constraints that make them hard to defend.

The main threat to a device is malware 恶意软件 - malicious software. Learn the types:

• Virus 病毒 - attaches to a host file or program and runs when that host executes; opening an infected file is one possible trigger.
• Worm 蠕虫 - spreads by itself, with no human action.
• Trojan 木马 - hides inside software that looks safe; a remote access trojan (RAT) 远程访问木马 gives the adversary remote control.
• Ransomware 勒索软件 - encrypts your files and demands payment for the key.
• Spyware 间谍软件 - secretly tracks what you do.
• Keylogger 键盘记录器 - records every keystroke to steal passwords.
• Logic bomb 逻辑炸弹 - triggers only when a condition is met (a date, a version).
• Rootkit - deeply hides in the operating system and can even make itself invisible.

Most malware is a file, but fileless malware 无文件恶意软件 is different: it lives only in RAM 内存 and abuses legitimate programs already on the device, leaving no file for a scanner to find.

Adversaries exploit unpatched software 未打补丁的软件, weak passwords, unprotected BIOS/UEFI startup settings, and open ports. We rate device risk by the value and criticality of the device - a hospital's unpatched email server is high risk, while an employee's laptop with one unused open port is low.

To store passwords safely, systems use a cryptographic hash function 密码散列函数 - a one-way maths algorithm that turns any input into a fixed-length string called a hash 散列值 (or digest). Hashes have three vital properties: they are collision resistant 抗碰撞 (hard to find two inputs with the same output), have pre-image resistance 抗原像 (recovering an input from a hash is computationally infeasible in general, although weak passwords can be guessed), and are repeatable (the same input always gives the same hash).

Try it — read real hash results. These inputs use UTF-8 with no final newline. Only the first 16 of each full SHA-256 hash's 64 hex characters are displayed.

Which rows illustrate repeatability? What stays fixed when input length changes? Do these results prove that collisions are impossible?

Worked reasoning. The two identical cat inputs give the same full hash. Both cat and cats have outputs of 64 hex characters. Each hex character represents 4 bits:

The changed output for cats illustrates sensitivity to an input change; three examples do not prove collision resistance. Matching prefixes alone do not establish that full hashes match. The full outputs in this worked example were checked.

Why collisions exist. An $n$-bit output has $N = 2^n$ possible values. A toy 4-bit hash has $N = 2^n = 2^4 = 16$ outputs. With 17 different inputs, at least two must share an output. This toy is not secure. Real cryptographic hashes have much larger output spaces, but collisions still exist; the goal is to make finding them computationally infeasible.

Real hash functions have names. The Secure Hash Algorithm (SHA) family – SHA-256 and SHA-512 – is today's standard. Adversaries attack a hash function by trying to force a collision (two different inputs with the same hash); once an efficient collision attack exists, that function is deprecated 弃用 (retired from secure use). MD5 and SHA-1 are the classic deprecated examples – never rely on them to protect data today.

A secure service should not store your plaintext password. It stores a salted password hash; when you log in, it hashes what you typed and compares. To stop two identical passwords producing identical hashes, a few random bits called salt 盐值 are added before hashing, so identical passwords do not normally produce identical stored hashes. Salt is stored with the hash and does not need to be secret.

Worked example. Two users both choose the password sunshine. Without salt, both stored hashes would be identical, so cracking one instantly cracks the other. Give each user a unique random salt - shortened here to x7 and q2 for readability - and the service hashes sunshinex7 and sunshineq2 instead. The two stored hashes now look completely different, so the adversary must attack each account separately. Salt prevents reuse of one unsalted lookup table across accounts, but does not make a weak password strong. This simple concatenation illustrates the idea; real password storage uses a purpose-built slow password-hashing scheme with a suitably sized unique random salt, not raw SHA-256.

Transfer — one-way does not mean unguessable. A stolen record has salt x7 and a SHA-256 hash. Its displayed prefix is f9325402a7a1542a. An adversary guesses rainbow and sunshine, appends the salt, hashes the results, and compares them with the record. The rainbowx7 prefix is 2a0e6ce47f2c701d; sunshinex7 begins f9325402a7a1542a. Which guess should be checked in full? Was the hash decrypted? Would live account lockout stop these computations?

Worked answer. The full sunshinex7 hash matches the stored value; the full rainbowx7 hash does not. This is guessing, hashing and comparing, not decryption. The salt was known, and the weak password was still guessed. Account lockout controls live login attempts; it does not stop computations on a stolen database. The guesses generate no login events at the service, although database theft or later use of the credentials may leave evidence.

Adversaries fight back with password attacks. Online attacks submit credentials to a live login; offline attacks steal the hash database and crack it on their own machine (which bypasses any account-lockout protection). Techniques include:

• brute force 暴力破解 - an automated tool tests all candidates in a chosen search space. Exhaustive search finds a match if the space includes the password and every candidate can be tested, but the cost may be impractical. For length $L$ with $A$ choices per position, the candidate count is $N = A^L$. Real attacks often try likely choices first.
• a dictionary attack 字典攻击 - the tool tries a list of common words and known passwords first, because most people pick guessable ones.
• password spraying 密码喷洒 - one common password against many accounts (this dodges lockout, which counts failures per account).
• credential stuffing 撞库 - reusing stolen or default credentials, exploiting that people reuse passwords across sites.
• a rainbow table 彩虹表 - a precomputed table of passwords and their hashes, sorted by hash, so a captured hash can be looked up instead of recomputed.

Password policy settings

An administrator hardens accounts by configuring login settings - and the exam expects you to name them and say what each defends against:

One subtlety worth a mark: some national standards now advise against forced expiry, because regular changes push users into predictable patterns like PasswordFall2028. A password manager 密码管理器 solves the real problem - it generates and stores a long, unique password per site, so none is ever reused or guessable.

Authentication factors prove who you are, and fall into categories: something you know (a password), something you have (a token or phone), something you are (a biometric 生物特征 like a fingerprint or retina scan), and somewhere you are (a location factor). Using two or more is multifactor authentication (MFA) 多因素身份验证 - far stronger than a password alone.

Removable media, and the autorun problem

An adversary can load malware onto an external drive — a USB stick, a portable disc — and leave it where someone will pick it up. If autorun 自动运行 is enabled, the device runs a program from that drive the moment it is inserted, with no click required, so the malware executes before the user has decided to trust anything.

Two controls answer this, and the exam wants both named:

• Disable autorun, so inserting a drive never runs anything by itself.
• Prohibit users from connecting external drives or media at all — enforced by policy and by a technical control that blocks the USB ports — which is why so many secure environments physically or logically disable them.

Managerial controls set the rules: an acceptable use policy 可接受使用政策 lists what users may and may not do, a password policy sets length and reuse rules, and a software installation policy controls what can be installed.

Technical controls do the work. Anti-malware software 反恶意软件 keeps a database of malware signatures and quarantines any file that matches. Keeping the operating system and applications updated - installing each patch 补丁 - closes known holes before adversaries can use them. A host-based firewall 主机防火墙 controls traffic in and out of one single device, blocking ports and services it does not need.

Devices log logins, file changes, and processes, and these logs reveal an indicator of compromise (IoC) 入侵指标 - evidence that an adversary got in. Host-based IoCs show up as unexpected processes or changed settings; file-based IoCs are files whose hash matches known malware; behaviour-based IoCs are things like many failed logins or unusual login times.

Choosing a detection method means weighing performance (signature-based is lighter, better for weak devices), cost (an endpoint detection and response (EDR) 端点检测与响应 service is powerful but expensive), and how sensitive the device is. Reading authentication logs exposes password attacks: many wrong passwords for one user signals a guessing attack; many users failing in quick succession is an indicator of password spraying; the AP course document also treats rapid default-credential attempts as an indicator of credential stuffing. These patterns need context; one shared IP address does not by itself prove an attack. Offline guesses create no live login events because they run on the adversary's copy; the theft or later use of the credentials may still be detected.

Speed is itself a security factor. Signature-based detection compares what it sees against a list of known-bad patterns, so it is faster than anomaly-based detection, which must first learn what normal looks like and then measure every event against that model. Anomaly-based detection catches attacks that have no signature yet, but it costs far more processing power — and on a device that lacks it, the effect compounds: the detection runs slowly, the device degrades, and the method ends up not being implemented effectively at all.

• Know each malware type by its defining trait: a worm self-spreads, a virus attaches to a host and runs when the host executes, ransomware encrypts for money, a RAT gives remote control, a rootkit hides.
• A hash is one-way and fixed-length; a unique salt changes the hashed input even when passwords match. A secure service should store a salted password hash, using a purpose-built slow scheme rather than raw SHA-256.
• Name real algorithms: SHA-256/SHA-512 are current; MD5 and SHA-1 are deprecated because efficient collision attacks exist.
• Match the password attack to its log signature: cite failed-login entries, timing and users. These are indicators, not proof. The AP CED includes default-credential attempts under stuffing.
• Sort authentication factors into know / have / are / where, and remember MFA combines two or more - a fingerprint plus a password, not two passwords.
• Offline guessing creates no live login events: the computations happen on the adversary's copy. Theft or later account use may still leave evidence.

Course terminology and implementation boundary. The AP CED 4.2.B.5 includes default-credential attempts under credential stuffing. OWASP's narrower definition focuses on replaying stolen username/password pairs across services. Use the AP definition for AP questions, while identifying the actual evidence and mechanism. The course's named general-purpose hashes illustrate hashing; they are not a recommendation to store passwords with plain SHA-256. See OWASP password-storage guidance and NIST hash properties.