Key Terms
| Term | Definition | Exam Context/Example |
|---|---|---|
| Authentication | The set of methods used to establish whether a claim of identity is true, verifying to a server or machine that you are who you say you are. | When using a payment card, entering the Personal Identification Number (PIN) completes the authentication portion of the transaction after identification has been asserted. |
| Identification | The simple assertion or claim of what someone or something is, but this process does not extend to verification or validation of that claim. | Swiping a magnetic strip on a card asserts the person indicated on the card is the user. Identification methods can include names, usernames, ID cards, or fingerprints. |
| Identity Verification | A step beyond identification but short of formal authentication; this is a superficial validation of identity. | Showing documents like a driver’s license, Social Security card, or birth certificate is generally for the purpose of identity verification. |
| Authorization | A separate task from authentication that determines what the authenticated party is permitted to do. | Authentication must take place first before authorization is determined. |
| Multifactor Authentication (MFA) | An authentication scheme that uses one or more authentication factors, offering a much stronger mechanism than a single factor. | In high-security environments, mutual multifactor authentication could be used, although this often results in a large loss of productivity. |
| Two-Factor Authentication (2FA) | A subset of multifactor authentication used specifically when only two factors are employed. | Using an ATM card (something you have) and a PIN (something you know) is a common example of 2FA. |
| Factors of Authentication | Categories of methods used to demonstrate identity, commonly broken down into five types. | To enhance security, factors can be combined, such as combining something you know with something you have. |
| Something You Know | An authentication factor based on knowledge possessed by the user, such as a password, PIN, passphrase, date of birth, or mother’s maiden name. | This is considered a somewhat weak factor because if the information is exposed, the uniqueness is nullified. |
| Something You Have | An authentication factor generally based on the physical possession of an item or device. | Examples include a mobile phone receiving a text message, a credit card, an ATM card, or a hardware token. |
| Something You Are (Biometrics) | An authentication factor based on the relatively unique physical attributes of an individual. | More complex identifiers commonly used include fingerprints, iris or retina patterns, or facial characteristics. |
| Something You Do | An authentication factor based on the actions or behaviors of an individual, sometimes considered a variation of “something you are”. | This includes gait (walking) recognition, handwriting analysis, or measuring the time delay between keystrokes. |
| Where You Are | A geographically based authentication factor that depends on the person being physically present at a particular location or locations. | This factor is commonly implemented by restricting server access to only a terminal located in the server room. |
| One-Time Password (OTP) | A password generated, typically by an app or device, that is only used a single time. | Online banking systems often use a device to produce a one-time password when a card and PIN are entered. |
| Hash-Based One-Time Password (HOTP) | A system where the OTP is generated by calculating the HMAC (hash-based message authentication code) of a secret key (S) and a counter (C). | The server and the generating device must be on the same counter number; the secret key is shared beforehand. |
| Time-Based One-Time Password (TOTP) | An extension of HOTP where the incrementing counter is replaced with the current time, often rounded to the nearest 30 seconds. | This system helps prevent problems caused by devices becoming accidentally out of sync with the server. |
| Hardware Token | A small physical device, often shaped like a credit card or keychain fob, used to aid authentication. | They may contain an internal clock and a unique identifier to generate a regularly changing code, typically every 30 seconds. |
| Enrollment (Biometrics) | The process of recording a chosen biometric characteristic from the user (e.g., a fingerprint) and storing it in the system for later matching. | Processing during enrollment may involve noting certain parts of the image to be used for matching. |
| Permanence (Biometrics Characteristic) | Measures how well a particular biometric characteristic resists change over time and with advancing age. | Factors like height or weight vary easily, while fingerprints are unlikely to be altered without deliberate action. |
| Circumvention (Biometrics Characteristic) | Describes the ease with which a biometric system can be tricked by a falsified biometric identifier. | The “gummy finger” attack, where a mold of a fingerprint is created using gelatin, is a classic example of this attack. |
| False Acceptance Rate (FAR) | A performance metric in biometrics that occurs when the system accepts a user whom it should actually have rejected (a false positive). | The FAR is typically balanced against the False Rejection Rate to achieve the Equal Error Rate. |
| False Rejection Rate (FRR) | A performance metric in biometrics that occurs when the system rejects a legitimate user who should have been accepted (a false negative). | ”Something you do” factors (like behavioral analysis) have the potential to incorrectly reject legitimate users at a higher rate than other factors. |
| Equal Error Rate (EER) | The balance point where the False Acceptance Rate (FAR) and False Rejection Rate (FRR) intersect on a graph; sometimes used as a measure of a biometric system’s accuracy. | Security systems aim for a balance between these two error types. |
| Passwords (Storage: Plain Text) | The naive and fundamentally insecure practice of storing the user’s password in the database exactly as it was typed in. | This is a monumentally bad idea because if the database is breached, hackers or insiders can read every user’s password immediately. |
| Passwords (Storage: Encryption) | Hiding the password using a key to lock it, allowing it to be unlocked later for checking. | If the encryption key is stolen, the passwords are still accessible; furthermore, multiple users with the same password will have the same encrypted code. |
| Passwords (Storage: Hashing) | Converting the password into a summary (gibberish) using a One Way Pseudorandom Function. | Although the hash cannot be reversed, common passwords will produce the same hash, making them vulnerable to online lookups or rainbow tables. |
| Salt | A random string of characters that is generated for each user and combined with the password before hashing. | Salting prevents common passwords from producing the same hash across different users, making brute-force and dictionary attacks significantly more difficult to carry out. |
| Password Entropy | The amount of information held within a password; low entropy means a smaller search space, allowing the password to be cracked quickly. | A password equal to or shorter than 8 characters is susceptible to brute force cracking. |
| Brute Force Cracking | An attack method involving trying every possible combination of characters in sequence until the correct password is found. | This attack becomes impractical for passwords longer than 9 or 10 characters, especially if large character sets (symbols, numbers, upper/lower case) are used. |
| Dictionary Attack | A cracking strategy that attempts to guess passwords by going through lists of commonly used words, names, or leaked passwords, often using complex rules to manipulate them. | This is much more effective than brute force for longer passwords, especially when leveraging lists like the RockYou database. |
| Rainbow Tables | Precomputed reverse-lookup tables that trade computation time for storage space, allowing attackers to quickly find the plaintext password corresponding to a given hash. | This attack is mitigated by using a unique salt for each user’s password. |
| Social Engineering | A technique relying on the willingness of people to help others, often used by skilled adversaries to manipulate users into compromising security measures. | The 2011 RSA breach started with a social engineering attack used to gain initial ingress to the corporate environment. |
| Phishing | A social engineering technique primarily using electronic communications (e.g., email, text) to entice a victim to click a link or open a malicious attachment. | Phishing links often direct the victim to fake sites that imitate legitimate ones (like banks) to steal personal information or credentials. |
| Spear Phishing | A targeted phishing attack against a specific individual, company, or organization that requires advanced reconnaissance to appear legitimate. | The email vehicle is carefully constructed with proper logos and language, often appearing to come from a trusted sender like HR or a manager. |
| Pretexting | A social engineering technique where the attacker assumes a fake identity (like a manager or co-worker) to create a believable scenario designed to extract sensitive information. | An attacker might use pretexting to drop names and provide details on the organization to gain the victim’s trust and elicit information. |
| Tailgating (Piggybacking) | The physical act of following someone through an access control point (like a secure door) without possessing the proper credentials. | This issue is common in locations with technical access controls and often succeeds because people want to avoid confrontation. |
| Mutual Authentication | An authentication mechanism where both the client and the server authenticate each other. | This approach is crucial because it leaves the system less vulnerable to impersonation or man-in-the-middle attacks. |
| Man-in-the-Middle Attack (MITM) | An impersonation attack where the attacker inserts himself between the client and the server, impersonating the server to the client and the client to the server. | This attack can be carried out by placing a “skimmer” over a normal ATM to intercept card information. |
Hashing vs Salting
Hashing and salting are two distinct steps essential for protecting passwords stored in a database, particularly against the risk of a breach.
Difference Between Hashing and Salting
Hashing Hashing is the process of converting a plaintext password into a summary or “gibberish” using a One Way Pseudorandom Function. This is done so that the actual password is never stored in the database. When a user attempts to log in, the system computes the hash of the password they supply and compares it to the hash already stored in the database. If the hashes match, the user is authenticated. A key property of hashing is that it is a one-way process, meaning the gibberish hash cannot be reversed to reveal the original password.
Salting Salting is the practice of adding a unique, random string of characters, known as the salt, to the user’s plaintext password before the password is run through the hashing function. A unique salt is generated for each user and both this salt and the final resulting hash are stored in the password database.
The Risk of Hashing Without Salting
If a system uses hashing but neglects to include a unique salt for each user (known as simple hashing), it opens the system up to major vulnerabilities.
The primary risks of hashing without salting are:
- Duplicate Hashes: If multiple users choose the same common password (such as “123456” or “password”), they will all generate the exact same hash. Even without the encryption key, an attacker can identify that all these accounts share the same password.
- Rainbow Table Attack: The uniformity of hashes for common passwords makes them highly vulnerable to rainbow tables.
- A rainbow table is a precomputed reverse-lookup table that trades computation time for storage space. Attackers calculate the hashes for billions of common passwords beforehand and store these combinations.
- When a database breach occurs and stolen hashes are dumped, the attacker can quickly look up the hash in the rainbow table to find the corresponding plaintext password in just a few seconds.
- This attack is highly effective against older or less robust hashing algorithms like MD5 or unsalted SHA-1. For example, after a 2012 breach where unsalted SHA-1 was used, 90% of the passwords were decrypted in 72 hours.
Why Both Hashing and Salting are Necessary
Both steps are necessary because they work together to eliminate the weaknesses associated with storing passwords:
- Hashing protects against database disclosure: Hashing prevents curious system administrators or intruders who gain access to the database from reading the passwords directly, as they are stored as non-reversible gibberish.
- Salting protects against mass cracking: By generating a random, unique salt for each user and combining it with the password before hashing, the same password used by two different users will result in two completely different hashes. This completely nullifies the effectiveness of the rainbow table attack.
- Impracticality for Attackers: Salting makes it nearly impossible for an attacker to prepare an encrypted dictionary (like a rainbow table) in advance. The attacker is forced to treat every single stolen hash as unique, requiring them to try every possible common password combined with the unique salt attached to that specific user’s account. This requirement makes brute-force and dictionary attacks against the compromised database significantly more difficult to carry out.
To truly secure passwords, developers must combine salting with a slow, CPU-intensive hash function, such as bcrypt or PBKDF2, to maximize the work an attacker must perform for each guess.
Analogy:
Imagine hashing is like mixing sand into concrete to hide a message—it’s impossible to reverse the process and pull the original sand grains back out. Using an unsalted hash is like mixing the same recipe of concrete for everyone; if a burglar steals the concrete and finds that 1,000 pieces all look identical, they know those 1,000 people used the same sand (password). Salting is like making sure everyone gets a unique, randomly colored pebble mixed into their concrete before it sets. Now, even if two people used the same sand, their concrete (hash) looks completely different, forcing the burglar to test millions of unique combinations of sand and pebbles individually, making the crime impractically difficult.
Key Recommendations and Policies
1. Password Complexity and Strength
The goal of constructing a strong password is often better described as making it complex.
| Recommendation Area | Details |
|---|---|
| Minimum Length | Passwords equal to or shorter than 8 characters are susceptible to brute force cracking. Recommended minimum lengths are generally eight characters, but ideally longer, up to 16 characters for critical systems. |
| Character Sets | Passwords should be constructed of a mix of uppercase letters, lowercase letters, numbers, and symbols. For example, a password using all four character sets and eight characters long might take over 2 years to crack with an average workstation. |
| Content Restriction | Passwords must not be a dictionary word, a name, a birthdate, or based on other personal information (e.g., pet names, mother’s maiden name, or social security numbers). |
| Risk Balance | The complexity of the password should be balanced with the importance of what is being protected. A minimum of eight characters may be fine for a family photos site, but not recommended for a bank account. |
2. Password Storage Best Practices
The central tenet of password storage is to never store passwords in plaintext. Storing plaintext is considered a “monumentally bad idea” because if the database is breached, the attacker can immediately read every user’s password.
| Recommendation Area | Best Practice |
|---|---|
| Avoid Plaintext & Encryption | Never store passwords in plain text. Additionally, do not use simple encryption (a two-way process), as the password remains visible if the decryption key is stolen, and multiple users with the same password will yield the same encrypted code. |
| Mandatory Hashing | Store passwords using a One Way Pseudorandom Function (hashing), which turns the plaintext into non-reversible “gibberish”. |
| Mandatory Salting | Password hashes must be salted. A random string (salt) must be generated for each user and combined with the password before hashing. The salt and the hash are stored in the database. This prevents common passwords from generating the same hash across different users and defends against rainbow table attacks. |
| Slow Hashing Algorithms | Use slow, CPU-intensive hash functions such as bcrypt, PBKDF2, scrypt, or Argon2. Standard fast hashes like SHA-256 or MD5 are considered poor password hash functions because they are too efficient, allowing attackers using high-end GPUs to compute billions of hashes per second. |
3. Password Expiration and Hygiene Policies
| Policy/Hygiene Area | Recommendation |
|---|---|
| Password Expiration | Organizations can enforce password expiration, requiring users to reset their password at some interval, such as 90 days. |
| Password History | Stipulate that new passwords cannot be a variation of the previous 10 passwords used, preventing users from trivially cycling passwords (e.g., incrementing a number or changing one letter). |
| Password Reuse (Manual Syncing) | Never reuse passwords. Users should not manually synchronize the same password across multiple systems, applications, or external sites (e.g., work VPN, email, online gaming). If one system is compromised, all accounts are compromised. |
| Physical Security | Users must handle passwords appropriately and not record them or leave them out where they might easily be compromised, such as writing them down and posting them under a keyboard or on a monitor. |
Consensus on Complexity vs. Passphrase Length
The sources indicate that password security researchers often discuss password entropy (the amount of information held in a password). However, practically, security depends on ensuring a password is long enough to resist brute force and complex enough to resist dictionary attacks.
The current consensus favors length (passphrases) over enforcing strict complexity rules involving substitution and symbols, especially because attackers often have comprehensive rule sets designed to defeat common substitutions (like replacing ‘e’ with ‘3’).
- Length Defeats Brute Force: If a password is nine characters or longer, and utilizes symbols, it is generally safe from being cracked by brute force methods. Longer passwords are inherently “un-brute-forceable”.
- Dictionary Attacks and Word Choice: Attacks on longer passwords (passphrases) shift from brute force to dictionary attacks. The risk then becomes the likelihood of the chosen words appearing in password lists (like the RockYou database).
- Optimal Strategy: A very strong password is a long passphrase constructed of multiple words (e.g., three English words, with one word that is “out there” or odd). The key is to select hard words (e.g., brand names or words not commonly used) to make the search space smaller for attackers using dictionary tools.
- Adding Complexity to Length: While length is key, complexity can still enhance security. Adding an unusual symbol (like an ampersand) in the middle of a word within a long passphrase (e.g.,
ho&rse) makes the password much harder to crack because it deviates from standard password substitution rules.
In summary, a lengthy passphrase using uncommon words that is easy for the user to remember, but computationally very difficult to guess (avoiding brute force by length and dictionary attacks by obscure word selection), is recommended.
Typical Phishing Attack Lifecycle (Attacker’s Perspective)
The typical phishing attack cycle, primarily conducted through electronic communications like email or text, involves preparing the lure and collecting the stolen information:
- Preparation/Site Creation: The attacker must first create the mechanism for theft. This involves setting up a fake website designed to collect personal information or credentials, which typically copies a well-known site, such as a banking site, Facebook, or eBay. These sites can range from poorly designed imitations with clumsy attempts at similar design to cleverly crafted copies that are extremely difficult to distinguish from the legitimate page. Alternatively, the attacker may create a malicious attachment to be sent to victims.
- Lure/Enticement (The Phishing Attempt): The attacker uses electronic communication (e.g., email or text) to entice the victim to perform an action. This typically involves convincing the potential victim to click on the link to the fake site or open the malicious attachment. Most phishing attacks are broad in nature, relying on a small percentage of success over millions of attempts, and do not count on careful inspection by the recipient.
- Credential Harvesting/Malware Installation: If the victim clicks the link, they are redirected to the fake site. If the purpose is credential theft, the site collects sensitive data. If malware is involved, the action causes the victim to install malicious software on their system. After obtaining the password, the fake site may even forward the user to the legitimate login page, leaving the user unaware that their password was just stolen.
For Spear Phishing, an additional initial step of Advanced Reconnaissance is required so that the attack vehicle appears legitimate and directs the victim to a site they would expect. The email is carefully constructed using proper logos, graphics, and language to appear to come from a trusted sender (e.g., HR or a manager).
Social Engineering Techniques Used in Phishing Emails
Phishing is a specific social engineering technique that relies on the willingness of people to help others. Although the sources do not explicitly list “urgency,” “authority,” and “appeal to fear” as a definitive three-part list, they describe how attackers manipulate trust and circumstances to achieve their goals:
- Impersonating Trusted Authority/Source: Phishing (especially spear phishing) often involves having the email appear to come from a valid sender whom the victim would trust, such as someone from human resources, a manager, the corporate IT support team, a peer, or a friend. This technique leverages the victim’s trust in a perceived authority or familiar figure.
- Creating a Believable Scenario (Pretexting/Context): In a targeted attack (spear phishing), the attacker uses advanced reconnaissance to create a believable scenario where the email vehicle will be seen as legitimate. Pretexting, a related social engineering technique, involves the attacker assuming a fake identity (like a manager or co-worker) to create a plausible situation designed to elicit sensitive information or an action. The attacker might “drop names” or provide details on the organization to gain the victim’s trust.
- Exploiting Lack of Scrutiny/Reliance on Frequency: General phishing relies on the target not carefully inspecting the message. By sending hundreds of thousands or millions of attempts, the attackers exploit the fact that people are “gullible” and a small percentage will connect to the attacker’s server, regardless of the quality of the imitation. The attack is successful when the user is too inattentive or distracted to notice that their password was stolen.
Key Phishing Attempt Identifiers
| Category | Indicator |
|---|---|
| Technical Indicators | Suspicious Links or URLs |
| The message attempts to entice the victim to click a link to a fake site designed to collect credentials or personal information. | |
The link destination URL uses shortened formats (e.g., http://bit.ly), which should be treated with suspicion. | |
The link URL uses a name that differs slightly from the expected name (e.g., myco.org instead of myco.com). | |
| The website design is a poorly designed imitation of a legitimate site, potentially with clumsy attempts at similar design or terrible grammar. | |
| The email appears to come from an unusual sender or contains an insecure link. | |
| Malicious Attachments | |
| The message includes an attachment from people that you do not know. | |
| The message includes attachments containing certain file types that are frequently used for malware, such as .exe, .zip, or .pdf files. | |
| Psychological/Contextual Indicators | Impersonation and Trust |
| The attacker assumes a fake identity (pretexting), such as a co-worker or manager, to create a believable scenario designed to elicit information. | |
| The email appears to come from a valid sender whom the victim would trust (e.g., HR, IT support, or a manager). | |
| The message is a targeted attack (spear phishing) that uses proper logos, graphics, and language (sometimes requiring advanced reconnaissance) to appear legitimate. | |
| Manipulation and Urgency | |
| The attempt relies on the victim being distracted or not carefully inspecting the message. | |
| The attack relies on social engineering by leveraging the human willingness to help others, particularly when faced with someone who appears distressed or intimidating. | |
| The communication seeks to have the victim divulge passwords or perform some action they would not normally do for a stranger. | |
| Post-Login Behavior | |
| If you logged in but the site immediately forwards you to the legitimate page or fails to show an error, be suspicious, as the attacker may have stolen your credentials and successfully logged you into the real site to avoid cluing you in that something strange has happened. | |
| Recommended User Action | |
| Users should maintain a healthy sense of paranoia so that their default action, instead of immediately clicking, is to contact the helpdesk or security team to ask about the message first. | |
| Both technical authentication controls (like two-factor authentication and strong hashing) and user awareness training (like identifying phishing) are crucial defense layers, but they protect against different threats and have different inherent weaknesses. |
Comparison of Defense Layers
| Defense Layer | Primary Mechanisms | Role in Security | Weakness/Vulnerability |
|---|---|---|---|
| Technical Authentication Controls | Multifactor authentication (MFA/2FA) (e.g., something you know + something you have) strong password hashing (salted, slow algorithms like bcrypt) and mutual authentication. | These mechanisms aim to verify the claim of identity when a user attempts to access a resource and ensure that even if a password database is breached, the stored credentials are not easily reversed or cracked. | Technical controls can be inconvenient for users, potentially leading to productivity loss or users working around them. They also rely on the client device being secure; if the “something you have” device is lost or broken, the user can be locked out. They can also be compromised by sophisticated attacks like Man-in-the-Middle (MITM) attacks if mutual authentication is not used. |
| User Awareness and Training | Security awareness programs, covering topics like social engineering, phishing, clean desk policies, and strong password hygiene. | These methods aim to modify user behavior in the direction of being more secure, by making users aware of the risks they are accepting through their actions. They are the only defense against human manipulation, like social engineering attacks. | User training can suffer from low retention rates and requires constant repetition (e.g., quarterly or monthly training rather than annual training). Even with the best intentions, bad decisions on the part of users can nullify all technical measures with a single click. |
Defense Layer Most Susceptible to Failure
In an organizational setting, the defense layer most susceptible to failure is user awareness and training (the human element).
This is supported by the sources for the following reasons:
- Humans are the Weak Link: Security professionals spend significant resources on technical controls (firewalls, web proxies, mail filtering, etc.), but “bad decisions on the part of our users can nullify all of these measures with a single click”. This reliance on human judgment is why security professionals often refer to humans as the “weak link” in the system.
- Susceptibility to Social Engineering: Human behavior is easily exploited by skilled adversaries. Social engineering techniques, such as phishing or pretexting, rely on manipulating the human willingness to help others or exploiting a lack of scrutiny, allowing an attacker to gain ingress to a system or cause highly sensitive information to be stolen. For instance, the major RSA breach in 2011 began with an initial intrusion achieved through a social engineering attack.
- Fragile Password Hygiene: Even when technical controls enforce strong passwords, user actions can compromise them. Users often write passwords down, post them in conspicuous places, or, most damagingly, manually synchronize the same strong password across multiple external and internal systems. If an external, less-secure system (like an online forum) is compromised, the synchronized password gives the attacker access to all of the user’s accounts, including work VPN credentials and email.
- Inconvenience of Technical Controls: While technical controls like MFA are effective, they are only implemented successfully if users accept them. Security must be a compromise between additional security and the ease of use. If security is too cumbersome (e.g., mutual multifactor authentication in a high-security environment), it results in a “very large loss in productivity”. Users who find security tools inconvenient may seek ways to circumvent them, such as leaving passwords recorded under a keyboard.
In essence, while technical controls require an attacker to breach a system through computational means or vulnerability exploitation (e.g., brute force cracking or MITM attacks), user training fails when a user simply makes a mistake, is distracted, or is successfully manipulated.
Short Answer Exam Questions
| Question | Answer |
|---|---|
| 1. Differentiate between Identification and Authentication using the example of an ATM transaction. | Identification is the claim of what someone is (swiping the magnetic strip on the card), but it does not involve verification. Authentication establishes whether this claim is true (entering the PIN). |
| 2. What is the fundamental security risk associated with storing user passwords using simple hashing (without salt)? | Simple hashing, where hash = h(pw), makes the system vulnerable to rainbow table attacks. An attacker can use precomputed reverse-lookup tables that map common hashes back to plaintext passwords. Additionally, users who choose the same password (e.g., “123456”) will generate the same hash, allowing an attacker to identify multiple compromised accounts. |
| 3. What is the purpose of the 12-bit random number (salt) in the historical UNIX password security scheme? | The salt, a 12-bit random number, is obtained when a password is first entered and is appended to the user’s password before encryption. This modification makes it nearly impossible to prepare an encrypted dictionary (rainbow table) in advance, and multiplies the effort required to test a given character string against a large collection of encrypted passwords by 4,096 (2^12). |
| 4. Name three of the five traditional Factors of Authentication and provide an example for each. | The five factors are: Something You Know (e.g., password, PIN); Something You Have (e.g., ATM card, hardware token, mobile phone receiving a text message),; Something You Are (e.g., fingerprints, iris patterns, biometrics),; Something You Do (e.g., gait recognition, time delay between keystrokes),; and Where You Are (e.g., restricting access to a terminal in the server room). |
| 5. Explain the difference between HOTP and TOTP used in generating one-time passwords for multifactor authentication. | HOTP (Hash-Based One-Time Password) is generated by calculating the HMAC of a secret key (S) and a counter (C). TOTP (Time-Based One-Time Password) is an extension of HOTP that replaces the incrementing counter with the current time (often rounded to the nearest 30 seconds), ensuring that the server and device are roughly synchronized. |
Exam Style Questions
Scenario-Based Long-Form Exam Questions
Scenario 1: Authentication Strategy for a High-Security Environment
A financial institution is building a new, extremely high-security data center where access to the main server room must be protected by robust authentication. The system needs to maximize security, tolerate a minor loss in productivity, and prevent unauthorized physical access (tailgating).
Question: Propose a three-factor authentication (3FA) scheme for server room access based on the factors discussed in the sources, justifying the inclusion of each factor. Discuss how this scheme specifically addresses the risk of tailgating and how it compares in productivity to a standard two-factor ATM transaction.
Answer:
The proposed 3FA scheme for the high-security server room should combine one factor from “Something You Have,” “Something You Are,” and “Where You Are” or “Something You Do” to ensure a high level of security.
Proposed 3FA Scheme:
- Something You Have (Hardware Token/Access Card): The user must possess a purpose-built hardware token or access card to initiate the transaction. For enhanced security, this token could include a keypad requiring a PIN (adding a second factor).
- Something You Are (Biometrics): The user must authenticate using an iris or retina scanner. Iris scanners are often considered more acceptable to users as they do not require physical touch, and they use identifiers (iris patterns) with a higher degree of uniqueness than simpler biometrics like height or weight.
- Where You Are (Geographical Control): Access to the server resources should only be possible from terminals physically present in the server room. This factor ensures that authentication attempts originating from remote locations are blocked.
Addressing Tailgating:
Tailgating (or piggybacking) is the physical act of following someone through an access control point without possessing the proper credentials. This is a “problem endemic to locations which use technical access controls”.
The inclusion of the Something You Are (Biometrics) factor directly mitigates tailgating. Even if a user holds the door open for an unauthorized person (to avoid confrontation or out of laziness), the unauthorized person will fail the mandatory biometric scan (iris recognition) required for access. Physical security mechanisms, like a turnstile requiring separate, successive scans, would further limit this risk, though the biometric scan itself is the definitive factor preventing access by the unauthenticated party.
Productivity Comparison:
This 3FA scheme is significantly slower than a standard two-factor ATM transaction.
- A standard ATM transaction uses only Something You Know (PIN) and Something You Have (ATM card), which is a quick, two-step process.
- The proposed 3FA scheme requires initiating with a physical object, performing a biometric scan (enrollment must take place first), and accessing the resource from a specific location.
The sources note that while more security is generally better, security must be balanced with ease of use. Implementing extremely strong authentication, such as mutual multifactor authentication, can result in a “very large loss in productivity”. The proposed 3FA scheme accepts this loss in productivity because the assets being protected (data center resources) warrant security that is “reasonably proportionate to what we are protecting”.
Scenario 2: Defense Against Account Compromise
An organization recently suffered a data breach where a large number of employee password hashes were stolen, and several users had their accounts compromised due to password reuse across personal sites.
Question: Based on the sources, recommend three essential technical measures and two essential user awareness/hygiene practices this organization must implement immediately to defend against current and future account compromises. For each recommendation, briefly explain how it mitigates the attack vector.
Answer:
To defend against current and future account compromises, the organization must strengthen its technical controls and address the inherent weaknesses of the human element.
Essential Technical Measures (To Defend Stolen Hashes and Future Breaches):
- Mandatory Password Salting: The organization must immediately switch to a salted hashing scheme. A unique random string (salt) must be generated for each user and combined with the password before hashing. This is critical because it invalidates precomputed rainbow tables and ensures that even if two users chose the same password, they produce different hashes, preventing mass decryption of credentials.
- Use Slow, CPU-Intensive Hash Functions: The organization should migrate to hash functions specifically designed for password hashing, such as bcrypt, scrypt, PBKDF2, or Argon2. Fast hash functions like MD5 or SHA-256 are too efficient, allowing attackers using GPUs to compute billions of hashes per second. Slow hashes make the cracking process “insurmountably harder”.
- Implement Multifactor Authentication (MFA/2FA): The organization must implement 2FA/MFA, requiring a second factor like a hardware token or phone-based OTP in addition to the password. This stops an attacker from breaking into an account even if they correctly guess or crack the password, as they will lack possession of the required device.
Essential User Awareness/Hygiene Practices (To Defend Against User Error):
- Enforce Strict Password Non-Reuse Policy: Users must be repeatedly educated that they should never reuse the same password across multiple systems, applications, or external sites (e.g., online gaming, forums). If one external system is compromised, password reuse places the security of all associated work accounts at risk. Password managers can be recommended to help manage unique, strong passwords.
- Continuous Security Awareness Training (Social Engineering): Users must receive reoccurring training (quarterly or monthly is better than annual) covering social engineering and phishing to modify their behavior. Training should focus on making users aware that their “bad decisions… can nullify all of these measures with a single click”. This is the only defense against human manipulation, such as pretexting or clicking on links in spear phishing emails that install malware or steal credentials.