Security Wiki

🔑 Passwords and passphrases

A password is a secret string of characters used to prove identity or protect access to a resource. A passphrase is a longer sequence of words, often with separators or numbers, designed to be easier for humans to remember while remaining hard for computers to guess.

Character-based passwords

These are the traditional strings built from a character pool: uppercase letters, lowercase letters, digits, and special symbols. Their strength depends on two factors: length and pool size (how many different characters are allowed).

A 12-character password using uppercase, lowercase, and digits has a pool of 62 characters. The total number of possible combinations is 6212, which is roughly 3.2 × 1021.

Passphrases (XKCD-style)

Popularized by the XKCD comic "Password Strength," a passphrase combines random dictionary words. For example: correct-horse-battery-staple. The idea is that four common words, chosen randomly from a pool of a few thousand, can produce enormous entropy while being memorable.

When to use which

🎲 Entropy and password strength

Entropy is a measure of randomness, expressed in bits. In password security, it tells you how many guesses an attacker would need to make, on average, to find your password by brute force.

The formula

E = L × log₂(R)

Where E is entropy in bits, L is length, and R is the size of the character pool. For example, a 16-character password using 62 possible characters has 16 × log₂(62) ≈ 95 bits of entropy.

Entropy benchmarks

* Assumes 100 trillion guesses per second (modern GPU cluster). Real-world attacks are usually much slower due to rate limiting and hashing costs.

🆔 Universally unique identifiers (UUID)

A UUID (Universally Unique Identifier) is a 128-bit number used to identify information in computer systems. The goal is not secrecy — it is uniqueness. The chance of two properly generated UUIDs colliding is astronomically low.

UUID versions

When to use UUIDs

• Database primary keys: Avoids exposing sequential IDs and simplifies distributed systems.
• API tokens / session IDs: As long as they are not the sole security factor.
• File names: Prevents collisions when uploading files from multiple users.
• Transaction IDs: Traceable across microservices without a central counter.

🔒 Cryptographic hashing

A hash function takes an input of any size and produces a fixed-size output called a digest. A cryptographic hash function has four critical properties:

1. Deterministic: The same input always produces the same output.
2. One-way: It is computationally infeasible to reverse the hash back to the original input.
3. Avalanche effect: A tiny change in input produces a completely different output.
4. Collision-resistant: It is extremely unlikely that two different inputs produce the same output.

Common hash algorithms

Hashing for password storage

Plain hash functions like SHA-256 are not suitable for storing passwords. They are too fast. An attacker with a GPU can test billions of passwords per second.

For passwords, you need a slow hash function:

• bcrypt: Adaptive cost factor. The standard for many years.
• scrypt: Memory-hard. Resistant to GPU and ASIC attacks.
• Argon2: Winner of the Password Hashing Competition (2015). Memory-hard, tunable, modern standard.
• PBKDF2: Older, still acceptable with high iteration counts (≥ 600,000).

🔁 Encoding and decoding

Encoding transforms data from one format to another. It is not encryption — there is no secret key, and anyone can reverse it. Encoding is about compatibility and transport, not security.

Common encoding schemes

When to use encoding

• Base64: Embedding images in CSS/HTML, sending binary data in JSON, email attachments (MIME).
• Hex: Displaying hash digests, representing raw bytes in a readable form.
• URL encoding: Passing special characters in query parameters or form data.

🗝️ Key derivation functions

A Key Derivation Function (KDF) takes a password (or any low-entropy input) and stretches it into a high-entropy cryptographic key. KDFs are deliberately slow and memory-intensive to resist brute-force attacks.

How they work

A KDF applies a hash function thousands or millions of times, often with a salt and memory-hard operations. This means:

• Legitimate users wait a fraction of a second.
• Attackers must spend the same fraction of a second per guess, making large-scale brute force prohibitively expensive.

Types of KDFs

🧂 Salt, pepper, and why they matter

When two users choose the same password, their hashes will be identical unless you add randomness. Salt and pepper solve this.

Salt

A salt is a random string unique to each password, appended (or prepended) before hashing. It ensures that even identical passwords produce different hashes. Salts are stored alongside the hash in the database.

hash = bcrypt(password + salt)

Without salt, an attacker can pre-compute hashes for common passwords (rainbow tables) and instantly crack any match. With salt, every password must be attacked individually.

Pepper

A pepper is a secret key stored outside the database (e.g., in an environment variable or HSM). It is combined with the password before hashing, but unlike salt, it is the same for all users and never stored with the hashes.

hash = bcrypt(password + salt + pepper)

If the database is leaked but the pepper is not, the attacker cannot crack any password without also obtaining the pepper.

⚡ How passwords are cracked

Understanding attack methods helps you appreciate why length, entropy, and slow hashing matter.

Brute force

Trying every possible combination of characters. A 6-character lowercase password has 26⁶ = 308 million combinations. A modern GPU can test this in seconds. A 12-character mixed password has 62¹² ≈ 3 × 10²¹ combinations — impossible to brute force.

Dictionary attack

Instead of random characters, the attacker tries words from a dictionary. password123 and qwerty fall instantly. Even CorrectHorseBatteryStaple is vulnerable if the attacker knows you use XKCD-style passphrases and has the same wordlist.

Rainbow tables

Pre-computed tables mapping hashes to plaintext passwords. Defeated entirely by salting, because each salt requires a new table.

Credential stuffing

Using username/password pairs leaked from one breach to log into other services. Works because people reuse passwords. Defeated by unique passwords per service.

Social engineering

Tricking a human into revealing a password. No amount of entropy protects against this. Defeated by security awareness and 2FA.

🛡️ Two-factor and multi-factor authentication

2FA requires two different types of evidence to prove identity. MFA extends this to two or more. The three categories of factors are:

1. Something you know: Password, PIN, security question.
2. Something you have: Phone, hardware key, smart card.
3. Something you are: Fingerprint, face scan, iris pattern.

Common 2FA methods

📁 Password managers

A password manager generates, stores, and autofills passwords. You only need to remember one strong master password. The manager handles the rest.

Why use one

• Unique passwords: Every account gets a different, random password.
• Strong passwords: No need to remember them, so they can be 30+ characters.
• Phishing resistance: Managers only autofill on the correct domain.
• Audit: Detect reused or breached passwords.

Types

✅ Best practices checklist

• Use a password manager and let it generate passwords for you.
• Every account gets a unique password. Never reuse.
• Passwords should be at least 16 characters long, or use a 4+ word passphrase.
• Enable 2FA on every account that supports it.
• Prefer TOTP or hardware keys over SMS for 2FA.
• Store passwords with Argon2id, bcrypt, or scrypt — never MD5 or plain SHA.
• Always use a unique salt per password. Consider a pepper for extra defense.
• Never transmit passwords over unencrypted HTTP. Always use HTTPS/TLS.
• Implement rate limiting and account lockouts on login forms.
• Monitor for breached credentials using services like Have I Been Pwned.
• Rotate passwords after a confirmed breach, not on a fixed schedule.
• Never store passwords in plain text, in logs, or in version control.