Intermediate
Cryptography & PKI
#hashing
#password-security
Hashing Vocabulary
6 exercises — collision/preimage resistance, SHA-256 vs MD5, salting, password hashing (bcrypt, scrypt, Argon2), and HMAC.
0 / 23 completed
1 / 23
What is the correct definition of "collision resistance" for a cryptographic hash function?
Collision resistance is one of three core security properties of a cryptographic hash function:
• Collision resistance: computationally infeasible to find any two inputs x ≠ y where hash(x) = hash(y)
• Preimage resistance: given a hash output h, computationally infeasible to find ANY input x such that hash(x) = h (this protects against reversing a hash back to its input)
• Second preimage resistance: given a specific input x, computationally infeasible to find a DIFFERENT input y such that hash(x) = hash(y) — a stronger, more targeted version of collision resistance
Collisions must exist mathematically (infinite possible inputs, finite possible outputs), but a secure hash function makes finding one require an infeasible amount of computation. MD5 and SHA-1 are considered "broken" precisely because practical collision attacks were found against them.
• Collision resistance: computationally infeasible to find any two inputs x ≠ y where hash(x) = hash(y)
• Preimage resistance: given a hash output h, computationally infeasible to find ANY input x such that hash(x) = h (this protects against reversing a hash back to its input)
• Second preimage resistance: given a specific input x, computationally infeasible to find a DIFFERENT input y such that hash(x) = hash(y) — a stronger, more targeted version of collision resistance
Collisions must exist mathematically (infinite possible inputs, finite possible outputs), but a secure hash function makes finding one require an infeasible amount of computation. MD5 and SHA-1 are considered "broken" precisely because practical collision attacks were found against them.
2 / 23
Why is MD5 considered deprecated / unsafe for security purposes today?
MD5 (and, later, SHA-1) were broken by practical collision attacks — meaning an attacker could deliberately craft two different files/certificates/messages that hash to the identical value. This defeats the entire purpose of using a hash for integrity or signature verification, because an attacker could substitute a malicious file for a legitimate one without changing the hash.
Current recommendations:
• SHA-256 / SHA-512 (SHA-2 family): the current widely-deployed standard, no practical collision attacks known
• SHA-3: a newer standard with a different internal design (Keccak), providing an alternative if a weakness is ever found in SHA-2
• BLAKE3: a modern, extremely fast hash function gaining adoption for non-legacy use cases
MD5 and SHA-1 may still appear in non-security contexts (e.g. checksums for accidental corruption detection, git's historical use of SHA-1 for object addressing) but should never be used where an adversary might deliberately try to forge a match.
Current recommendations:
• SHA-256 / SHA-512 (SHA-2 family): the current widely-deployed standard, no practical collision attacks known
• SHA-3: a newer standard with a different internal design (Keccak), providing an alternative if a weakness is ever found in SHA-2
• BLAKE3: a modern, extremely fast hash function gaining adoption for non-legacy use cases
MD5 and SHA-1 may still appear in non-security contexts (e.g. checksums for accidental corruption detection, git's historical use of SHA-1 for object addressing) but should never be used where an adversary might deliberately try to forge a match.
3 / 23
Complete the description: "SHA-256 produces a 256-bit digest regardless of input size. A single bit change in the input produces a completely different digest — this property is called the ___."
The avalanche effect is what makes hash outputs look completely uncorrelated even for near-identical inputs — changing a single bit of input should flip roughly half the output bits, unpredictably.
Related vocabulary:
• Digest: the fixed-size output of a hash function (also called a "hash value" or "hash")
• Fixed output size: regardless of whether you hash one byte or one gigabyte, SHA-256 always produces exactly 256 bits (32 bytes) of output
• Deterministic: the same input always produces the same output, every time
The avalanche effect is why hashes are useful for integrity checks: even a one-character change to a file (or a single flipped bit from corruption) produces a visibly different digest, making tampering or corruption detectable.
Related vocabulary:
• Digest: the fixed-size output of a hash function (also called a "hash value" or "hash")
• Fixed output size: regardless of whether you hash one byte or one gigabyte, SHA-256 always produces exactly 256 bits (32 bytes) of output
• Deterministic: the same input always produces the same output, every time
The avalanche effect is why hashes are useful for integrity checks: even a one-character change to a file (or a single flipped bit from corruption) produces a visibly different digest, making tampering or corruption detectable.
4 / 23
What is a "salt" in the context of password hashing, and what problem does it solve?
A salt is a unique random value added to a password before hashing, specifically to defeat precomputation attacks.
Without a salt: an attacker can precompute a huge lookup table (a "rainbow table") mapping common passwords to their hash values once, then instantly reverse-lookup any leaked hash — and if two users share a password, they'll have identical hashes, revealing the pattern.
With a salt: each password gets combined with a per-user random salt before hashing, so
Important: a salt is NOT secret — it's typically stored alongside the hash in plaintext. Its job is to guarantee uniqueness, not to add secrecy (that's what a "pepper," a separate application-wide secret, is sometimes used for).
Without a salt: an attacker can precompute a huge lookup table (a "rainbow table") mapping common passwords to their hash values once, then instantly reverse-lookup any leaked hash — and if two users share a password, they'll have identical hashes, revealing the pattern.
With a salt: each password gets combined with a per-user random salt before hashing, so
hash(salt + password) is unique per user even for identical passwords — a rainbow table would need to be recomputed separately for every possible salt, making the attack impractical.Important: a salt is NOT secret — it's typically stored alongside the hash in plaintext. Its job is to guarantee uniqueness, not to add secrecy (that's what a "pepper," a separate application-wide secret, is sometimes used for).
5 / 23
Why are bcrypt, scrypt, and Argon2 used specifically for password hashing instead of plain SHA-256?
General-purpose hash functions like SHA-256 are optimised for speed — great for checksums and digital signatures, but that same speed is a liability for password storage, because it lets attackers try billions of guesses per second on modern GPUs.
Password hashing algorithms (bcrypt, scrypt, Argon2) are deliberately slow and configurable:
• Work factor / cost parameter: a tunable setting (e.g. bcrypt's "rounds," Argon2's "iterations/memory/parallelism") that controls how much CPU time and/or memory is required per hash — increased over time as hardware gets faster
• Memory-hardness (scrypt, Argon2): deliberately requires significant RAM per hash attempt, which makes cheap, massively parallel GPU/ASIC cracking far less effective than with CPU-time-only algorithms
• Built-in salting: these algorithms handle salt generation and storage automatically as part of their standard output format
Argon2 (specifically Argon2id) is the current OWASP-recommended default for new applications.
Password hashing algorithms (bcrypt, scrypt, Argon2) are deliberately slow and configurable:
• Work factor / cost parameter: a tunable setting (e.g. bcrypt's "rounds," Argon2's "iterations/memory/parallelism") that controls how much CPU time and/or memory is required per hash — increased over time as hardware gets faster
• Memory-hardness (scrypt, Argon2): deliberately requires significant RAM per hash attempt, which makes cheap, massively parallel GPU/ASIC cracking far less effective than with CPU-time-only algorithms
• Built-in salting: these algorithms handle salt generation and storage automatically as part of their standard output format
Argon2 (specifically Argon2id) is the current OWASP-recommended default for new applications.
6 / 23
What does HMAC provide that a plain hash function alone does not?
A plain hash (e.g.
HMAC adds a signing key into the computation:
• Integrity: the message content hasn't been tampered with
• Authenticity: the message was created by someone possessing the shared secret key
Common uses: API request signing (e.g. AWS Signature V4, webhook payload signatures like Stripe's
SHA256(message)) only proves integrity — that the message hasn't changed since the hash was computed — but ANYONE can compute a hash, including an attacker who modifies the message and recalculates a new matching hash. It provides no proof of who created it.HMAC adds a signing key into the computation:
HMAC(key, message). Only someone who knows the secret key can produce a valid HMAC for a given message, so verifying the HMAC proves BOTH:• Integrity: the message content hasn't been tampered with
• Authenticity: the message was created by someone possessing the shared secret key
Common uses: API request signing (e.g. AWS Signature V4, webhook payload signatures like Stripe's
Stripe-Signature header), and as a building block inside TLS's record-layer integrity checks.7 / 23
Reviewer: 'I'm seeing a lot of MD5 hashes being used in the user authentication system. Are you sure that's secure? It seems like a really old algorithm.'
Which of the following best explains the reviewer's concern?The reviewer is concerned about collision resistance, a fundamental weakness of MD5. Because MD5 produces the same hash value for different inputs (collisions), an attacker could craft a malicious input that generates the same hash as a legitimate user's password, effectively bypassing authentication. While MD5 might be fast, its lack of security makes it unsuitable for sensitive applications like user authentication; modern algorithms are designed to mitigate this risk.
8 / 23
Senior Dev: 'Hey team, I'm seeing a lot of SHA-384 hashes being used for our API key storage. It seems pretty robust, right? We're using the latest TLS version and everything.' Junior Dev: 'I was reading about key derivation functions – it seems like SHA-384 is actually quite sensitive to precomputed tables.' What's Senior Dev likely missing in their assessment?Senior Dev is focusing solely on the TLS layer, assuming it provides complete protection. However, SHA-384's larger output size and susceptibility to precomputation attacks – where attackers can create tables predicting hash values based on input patterns – significantly increase the risk of key leakage. Junior Dev correctly identifies this vulnerability; a strong key derivation function must actively prevent these kinds of predictable relationships from forming.9 / 23
PR Description:
"Implemented a new user registration flow. Using SHA-256 for password hashing to ensure data integrity and prevent unauthorized access."
During code review, another developer comments: 'Just a heads up, using SHA-256 directly for password storage is increasingly discouraged. It's vulnerable to rainbow table attacks if the salt isn't properly managed and its output size might be exploited in certain scenarios.' Which of the following best describes the core issue raised by this comment?
The comment highlights the vulnerability of directly using SHA-256 for password hashing. While SHA-256 itself isn't fundamentally flawed, its fixed output size (256 bits) makes it susceptible to collision attacks if an attacker can predict the structure of the input. A key derivation function (KDF) like bcrypt or Argon2 introduces randomness and complexity, mitigating this risk by making precomputed tables ineffective – options 1 and 4 are incorrect as they misrepresent SHA-256's vulnerabilities and the role of a KDF.
10 / 23
Reviewer: 'I'm seeing a lot of MD5 hashes being used in the user authentication system. Are you sure that's secure? It seems like a really old algorithm.'
Which of the following best explains the reviewer's concern?The reviewer is concerned about collision resistance, a fundamental weakness of MD5. Because MD5 produces the same hash value for different inputs (collisions), an attacker could craft a malicious input that generates the same hash as a legitimate user's password, effectively bypassing authentication. While MD5 might be fast, its lack of security makes it unsuitable for sensitive applications like user authentication; modern algorithms are designed to mitigate this risk.
11 / 23
Senior Dev: 'Hey team, I'm seeing a lot of SHA-384 hashes being used for our API key storage. It seems pretty robust, right? We're using the latest TLS version and everything.' Junior Dev: 'I was reading about key derivation functions – it seems like SHA-384 is actually quite sensitive to precomputed tables.' What's Senior Dev likely missing in their assessment?Senior Dev is focusing solely on the TLS layer, assuming it provides complete protection. However, SHA-384's larger output size and susceptibility to precomputation attacks – where attackers can create tables predicting hash values based on input patterns – significantly increase the risk of key leakage. Junior Dev correctly identifies this vulnerability; a strong key derivation function must actively prevent these kinds of predictable relationships from forming.12 / 23
PR Description:
"Implemented a new user registration flow. Using SHA-256 for password hashing to ensure data integrity and prevent unauthorized access."
During code review, another developer comments: 'Just a heads up, using SHA-256 directly for password storage is increasingly discouraged. It's vulnerable to rainbow table attacks if the salt isn't properly managed and its output size might be exploited in certain scenarios.' Which of the following best describes the core issue raised by this comment?
The comment highlights the vulnerability of directly using SHA-256 for password hashing. While SHA-256 itself isn't fundamentally flawed, its fixed output size (256 bits) makes it susceptible to collision attacks if an attacker can predict the structure of the input. A key derivation function (KDF) like bcrypt or Argon2 introduces randomness and complexity, mitigating this risk by making precomputed tables ineffective – options 1 and 4 are incorrect as they misrepresent SHA-256's vulnerabilities and the role of a KDF.
13 / 23
Reviewer: 'I'm seeing a lot of MD5 hashes being used in the user authentication system. Are you sure that's secure? It seems like a really old algorithm.'
Which of the following best explains the reviewer's concern?The reviewer is concerned about collision resistance, a fundamental weakness of MD5. Because MD5 produces the same hash value for different inputs (collisions), an attacker could craft a malicious input that generates the same hash as a legitimate user's password, effectively bypassing authentication. While MD5 might be fast, its lack of security makes it unsuitable for sensitive applications like user authentication; modern algorithms are designed to mitigate this risk.
14 / 23
Senior Dev: 'Hey team, I'm seeing a lot of SHA-384 hashes being used for our API key storage. It seems pretty robust, right? We're using the latest TLS version and everything.' Junior Dev: 'I was reading about key derivation functions – it seems like SHA-384 is actually quite sensitive to precomputed tables.' What's Senior Dev likely missing in their assessment?Senior Dev is focusing solely on the TLS layer, assuming it provides complete protection. However, SHA-384's larger output size and susceptibility to precomputation attacks – where attackers can create tables predicting hash values based on input patterns – significantly increase the risk of key leakage. Junior Dev correctly identifies this vulnerability; a strong key derivation function must actively prevent these kinds of predictable relationships from forming.15 / 23
PR Description:
"Implemented a new user registration flow. Using SHA-256 for password hashing to ensure data integrity and prevent unauthorized access."
During code review, another developer comments: 'Just a heads up, using SHA-256 directly for password storage is increasingly discouraged. It's vulnerable to rainbow table attacks if the salt isn't properly managed and its output size might be exploited in certain scenarios.' Which of the following best describes the core issue raised by this comment?
The comment highlights the vulnerability of directly using SHA-256 for password hashing. While SHA-256 itself isn't fundamentally flawed, its fixed output size (256 bits) makes it susceptible to collision attacks if an attacker can predict the structure of the input. A key derivation function (KDF) like bcrypt or Argon2 introduces randomness and complexity, mitigating this risk by making precomputed tables ineffective – options 1 and 4 are incorrect as they misrepresent SHA-256's vulnerabilities and the role of a KDF.
16 / 23
Reviewer: 'I'm seeing a lot of MD5 hashes being used in the user authentication system. Are you sure that's secure? It seems like a really old algorithm.'
Which of the following best explains the reviewer's concern?The reviewer is concerned about collision resistance, a fundamental weakness of MD5. Because MD5 produces the same hash value for different inputs (collisions), an attacker could craft a malicious input that generates the same hash as a legitimate user's password, effectively bypassing authentication. While MD5 might be fast, its lack of security makes it unsuitable for sensitive applications like user authentication; modern algorithms are designed to mitigate this risk.
17 / 23
Senior Dev: 'Hey team, I'm seeing a lot of SHA-384 hashes being used for our API key storage. It seems pretty robust, right? We're using the latest TLS version and everything.' Junior Dev: 'I was reading about key derivation functions – it seems like SHA-384 is actually quite sensitive to precomputed tables.' What's Senior Dev likely missing in their assessment?Senior Dev is focusing solely on the TLS layer, assuming it provides complete protection. However, SHA-384's larger output size and susceptibility to precomputation attacks – where attackers can create tables predicting hash values based on input patterns – significantly increase the risk of key leakage. Junior Dev correctly identifies this vulnerability; a strong key derivation function must actively prevent these kinds of predictable relationships from forming.18 / 23
PR Description:
"Implemented a new user registration flow. Using SHA-256 for password hashing to ensure data integrity and prevent unauthorized access."
During code review, another developer comments: 'Just a heads up, using SHA-256 directly for password storage is increasingly discouraged. It's vulnerable to rainbow table attacks if the salt isn't properly managed and its output size might be exploited in certain scenarios.' Which of the following best describes the core issue raised by this comment?
The comment highlights the vulnerability of directly using SHA-256 for password hashing. While SHA-256 itself isn't fundamentally flawed, its fixed output size (256 bits) makes it susceptible to collision attacks if an attacker can predict the structure of the input. A key derivation function (KDF) like bcrypt or Argon2 introduces randomness and complexity, mitigating this risk by making precomputed tables ineffective – options 1 and 4 are incorrect as they misrepresent SHA-256's vulnerabilities and the role of a KDF.
19 / 23
Reviewer: 'The API is returning a JWT signed with an RSA key. I'm noticing that the private key is stored directly in the application code. Is this standard practice?'
Which of the following best explains the reviewer's concern?
Options:
insufficient — The API endpoint lacks proper rate limiting.
insufficient — Storing cryptographic keys directly in code poses a significant security risk, potentially leading to compromise if the codebase is accessed or leaked.
insufficient — The JWT claims are not being validated correctly against the user database.
insufficient — The RSA key size is too small for adequate security.Storing private keys directly in code is a major vulnerability. Attackers could gain access to these keys and forge valid JWTs, impersonating users or gaining unauthorized access to the API. This practice should *always* be avoided; instead, use secure key management systems like Hardware Security Modules (HSMs) or environment variables with restricted access.
20 / 23
Senior Dev: 'We're using a PKI to sign our TLS certificates. The root CA is managed by a third-party vendor. We've noticed some discrepancies in the certificate chains being returned from the load balancer – sometimes it's missing intermediate certificates.'
Which of the following best describes the potential issue?
Options:
insufficient — The load balancer isn't correctly configured to retrieve all necessary certificates.
insufficient — A corrupted root CA certificate is causing the chain validation failure, leading to connection errors.
insufficient — Missing intermediate certificates in the chain are causing the browser or client to reject the certificate, preventing secure connections.
insufficient — The TLS protocol itself is experiencing instability.PKI chains rely on a hierarchy of trust. Each certificate is signed by the one below it. If any intermediate certificate is missing from the chain presented to the client (e.g., by the load balancer), the client cannot verify the root CA's authenticity and will reject the connection, resulting in an error.
21 / 23
PR Description:
"Implemented a new user authentication flow. Using SHA-256 for password hashing to ensure data integrity and prevent unauthorized access."
During code review, another developer comments: 'While SHA-256 is generally considered secure, it's vulnerable to brute-force attacks if the password salt isn't sufficiently random and unique.'
What specific problem does the reviewer highlight?
Options:
insufficient — The PR doesn't implement any hashing algorithm.
insufficient — SHA-256 is not a suitable hash function for storing passwords due to its output size.
insufficient — The lack of a unique salt makes the password vulnerable to rainbow table attacks, significantly increasing the risk of successful brute-force attempts.
insufficient — The PR doesn't include any error handling for invalid passwords.A 'salt' is a random string added to each password before hashing. This prevents attackers from using precomputed rainbow tables (tables of hashes) to crack the passwords. Without a unique salt for *each* password, an attacker could use the same salt across multiple users, dramatically increasing the efficiency of a brute-force attack.
22 / 23
Junior Dev: 'I'm working on integrating a new API that uses X.509 certificates for client authentication. I've been using the
openssl command to generate these certificates.'
What is the primary purpose of using X.509 certificates in this scenario?
Options:
insufficient — To encrypt all data transmitted between the API and the clients.
insufficient — To digitally sign requests, verifying the identity of the client making the request.
insufficient — To create a secure tunnel for communication using TLS/SSL.
insufficient — To automatically manage user accounts and permissions.X.509 certificates are used to establish trust in a client-server relationship. The certificate contains the client's public key, which is used to verify the digital signature on requests from that client. This allows the API server to confirm the identity of the requesting client and prevent unauthorized access.
23 / 23
Reviewer: 'I'm seeing a lot of Base64 encoded strings being used in the configuration files. Is this really the best way to handle sensitive data like API keys?'
What is the main security concern associated with using Base64 encoding for secrets?
Options:
insufficient — Base64 encoding significantly increases the size of the configuration files, leading to performance issues.
insufficient — Base64 encoding provides strong encryption, protecting the API keys from unauthorized access.
insufficient — Base64 encoding is reversible, allowing an attacker to easily recover the original data if they obtain the encoded string.
insufficient — Base64 encoding simplifies the process of integrating with different systems.Base64 encoding is a *text-based* encoding scheme. It's easily reversible and provides no actual encryption. Storing sensitive data like API keys in Base64 makes them trivially accessible to anyone who obtains the encoded string – it's simply a disguised representation of the original value.
Frequently Asked Questions
What does the "Hashing Vocabulary — Cryptography & PKI Exercises" exercise cover?
Practise hash function vocabulary: collision resistance, preimage resistance, avalanche effect, salting, password hashing algorithms (bcrypt, Argon2), and HMAC. Intermediate exercises.
Is this exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is free to use with no account, sign-up, or paywall.
How many questions are in "Hashing Vocabulary — Cryptography & PKI Exercises"?
This exercise has 23 questions. Each one gives instant feedback with an explanation, so you can see exactly why an answer is right or wrong.
Do I need to create an account to save my progress?
No account is required. The progress bar and score are tracked in your browser for the current session -- the exercise is designed to be a quick, repeatable drill rather than something you resume later.
What happens if I get an answer wrong?
You'll see the correct answer highlighted immediately, along with a short explanation of why it's correct. Wrong answers aren't penalized beyond your score, and you can keep going through every question.
How is this exercise different from reading an article?
Articles explain vocabulary and concepts through prose, while exercises like this one are interactive drills -- multiple-choice questions -- that test and reinforce your recall of specific terms and phrasing.
Can I retry this exercise?
Yes -- use the "Try again" button on the results screen to reset your score and go through all the questions again from the start.
Where can I find more Cryptography & PKI exercises?
Browse the full Cryptography & PKI hub for related drills, or check the site-wide exercises index for other IT English topics.
Is this exercise suitable for beginners?
This exercise assumes basic familiarity with IT terminology. If a term feels unfamiliar, check the site Glossary for a plain-English definition before attempting the questions.
How often is new content like this published?
New exercises are added regularly across all categories, alongside new vocabulary sets and articles. Check back on the exercises hub to see what's new.