When we talk about a "strong" password, we're really talking about its entropy. Entropy is a measure of randomness or unpredictability. A password with high entropy is difficult for a computer to guess, not just a human. The calculation is straightforward: it depends on the number of possible characters and the password's length.

A password like password uses 8 lowercase letters. Its entropy is $8 \times \log_2(26)$, which is about 37.6 bits. That might sound like a lot, but a modern computer can crack that almost instantly.

Now consider a 12-character password using uppercase, lowercase, numbers, and 33 common symbols (a pool of 95 characters). Its entropy is $12 \times \log_2(95)$, or about 79 bits. An attacker would need to try trillions of times more combinations to guess this password, making it significantly more secure. This mathematical foundation is why length and character variety are so critical. It's not just a suggestion, it's a direct countermeasure to brute-force guessing.

No reputable service stores your password in plain text. If their database were ever stolen, every user's password would be exposed. Instead, they store a cryptographic hash of your password. A hash function is a one-way street. It takes an input (your password) and produces a fixed-length string of characters, called the hash. It's computationally impossible to reverse this process to get the original password from the hash.

When you log in, the service takes the password you just typed, runs it through the exact same hash function, and compares the result to the hash stored in its database. If they match, you're in. This way, the service never knows your actual password, only its fingerprint.

But simple hashing isn't enough. If two users happen to choose the same password, P@ssword123, they would both have the identical hash in the database. Attackers exploit this with pre-computed lists of hashes for common passwords, called rainbow tables. To prevent this, we use salting.

Because every user gets a unique salt, even identical passwords produce unique hashes. This renders rainbow tables useless. An attacker would have to compute a separate table for every single salt, which is completely infeasible. A related, though less common, technique is peppering, where a single, secret value (the pepper) is added to every password before hashing. The pepper is stored separately from the database, for example in the application's configuration file, adding another layer of security if only the password database is compromised.

Salting protects against pre-computation, but what if an attacker steals the database and decides to attack one password at a time? They could try billions of guesses per second on a powerful computer. This is where key stretching comes in. Modern hashing algorithms like Argon2, bcrypt, and PBKDF2 are designed to be deliberately slow.

They run the hashing calculation not once, but thousands or even millions of times. This iterative process is controlled by a parameter called a "work factor" or "cost." For a legitimate user logging in, the half-second delay this causes is unnoticeable. But for an attacker trying to make billions of guesses, that delay becomes a crippling bottleneck. It turns an attack that would take hours into one that could take decades or centuries.

This leads us to the two main ways an attacker tries to steal your credentials: online and offline attacks.

Online attacks are slow and noisy. A website might lock an account after five failed attempts. An offline attack is where strong credential architecture truly shines. Once an attacker has the hash database, they have unlimited guesses. Salting, peppering, and especially key stretching are the critical defenses that make cracking those stolen hashes computationally infeasible.

Time to see what you've learned about securing credentials.

Understanding these principles shows why simple advice like "use a long password" has deep cryptographic roots. It's all about making the math impossibly hard for those trying to break in.