Cryptography without the maths
Hashing, encryption, signatures and TLS each protect something different, and most real failures come from using the wrong one or losing the key. This lesson explains what each tool guarantees in plain words, how HTTPS proves who you are talking to, and why key management and certificate expiry cause more outages and breaches than broken algorithms.
By the end you can
- Choose between a hash, a password hash, encryption and a signature for a given need, and say what each one protects
- Explain what happens in a TLS connection and what a certificate does and does not prove
- Check a certificate's dates and names, including wildcard rules, in code
- Describe where keys should live, how envelope encryption and rotation work, and why keys never go in code
- Spot the common mistakes: encoding as encryption, fast hashes for passwords, home-made crypto, verification switched off, expired certificates
The everyday picture
Think about sending something valuable through a courier. You can write the parcel's weight on the label, so the receiver notices if anything was taken out. You can put it in a locked box, so nobody without the key can see inside. You can seal it with your personal wax seal, so the receiver knows it came from you and was not opened on the way. And before you hand it over, you check the courier's ID card, issued by an office you trust, to make sure you are giving it to the real courier.
Those four habits are the four tools of this lesson. The weight on the label is a hash: it detects change but hides nothing. The locked box is encryption: it keeps the contents secret from anyone without the key. The wax seal is a signature: it proves who sent it and that nothing changed. The ID card is a certificate: a trusted office vouching that this public key belongs to this name. HTTPS uses all four at once, every time an app talks to a server.
Hashing: a fingerprint you can't turn back
A hash function takes any input, a password, a 2 GB backup or one line of text, and produces a short fixed-size value called a hash or digest. SHA-256 always produces 256 bits, usually written as 64 hexadecimal characters. Three properties make it useful. The same input always gives the same hash. Changing one character of the input changes the hash completely. And nobody can work backwards from a hash to the input, or find two different inputs with the same hash (a collision).
That makes a hash a fingerprint. Mangrove's head office publishes the nightly price file with its SHA-256 hash; the Store app recomputes the hash after download and refuses a file that doesn't match, so a cut-off download is caught. Git commit ids and cache keys work the same way. But a hash has no key and hides nothing, and if an attacker can change both the file and the published hash, the check passes. Proving who published it needs a signature, which comes later.
MD5 and SHA-1 are broken for collisions (a public SHA-1 collision was shown in 2017, and MD5 fell long before), so use SHA-256 or another SHA-2 or SHA-3 function for new work.
Passwords need a special kind of hash. An attacker who steals a user table doesn't reverse the hashes. They guess: hash mango123, compare it with every stored hash, repeat. A graphics card computes billions of fast hashes like SHA-256 per second, so common passwords fall within minutes. Password hashing adds two defences:
- A salt: a random value per user, stored next to the hash. Two customers with the same password get different hashes, and precomputed tables become useless.
- A deliberate cost. OWASP's advice is Argon2id first, scrypt if Argon2id is not available, bcrypt for legacy systems, and PBKDF2 where FIPS-140 validated crypto is required. A login takes a fraction of a second; guessing slows down by many thousands of times.
You saw passwords from the user's side in Identity: passwords, MFA and passkeys; Authentication, sessions and tokens goes deeper for developers.
Quick check
Mangrove's old loyalty system stored each password as a plain SHA-256 hash. What is the main problem?
A hash has no key, so there is nothing to decrypt; the risk is guessing. Fast, unsalted hashes let an attacker test huge password lists cheaply and spot every customer who shares a password. 256 bits is far more than enough to keep hashes unique. The fix is a salted, slow password hash such as Argon2id, applied as each customer next logs in.