Encryption, Hashing and Authentication

Introduction

Security relies on a few mathematical tools that are easy to confuse. Knowing which one fits which job prevents serious mistakes, such as storing passwords the wrong way.

Three tools, three jobs

Encryption scrambles data so only someone with the key can read it. It is reversible. Use it to protect data you need to read again, such as messages or files.

• Symmetric encryption uses one shared key (for example AES). It is fast.
• Asymmetric encryption uses a key pair: a public key to encrypt and a private key to decrypt. It is used to start secure connections and share secrets.

Hashing turns any data into a fixed-size fingerprint, and it is one-way. You cannot get the original back. The same input always gives the same hash, and a tiny change gives a completely different one. Use it to check integrity or to store passwords.

Digital signatures use a private key to sign data, and anyone with the public key can verify who signed it and that it was not changed.

Storing passwords

Never store passwords in plain text, and never encrypt them in a way that can be reversed. Instead store a salted hash made with a slow algorithm designed for passwords.

• A salt is a random value added to each password before hashing, so two users with the same password get different hashes and precomputed tables do not work.
• Use a modern password hashing function such as Argon2id, scrypt or bcrypt, with settings recommended by current guidance. Fast hashes such as plain SHA-256 are too quick for attackers to guess billions of times.
• Use the well-tested functions in your language or framework. Never invent your own scheme.

When a user logs in, hash what they typed with the stored salt and compare with the stored hash.

Good password rules, according to modern NIST guidance: allow long passwords and passphrases, check against lists of breached passwords, do not force frequent changes without a reason, and support password managers.

Authentication and sessions

Authentication is proving who you are. After you log in, the server needs to remember you:

• A session stores your login state on the server, with a random ID in a cookie. Use secure cookie flags: Secure, HttpOnly and SameSite.
• A token such as a JSON Web Token carries signed claims. Validate the signature and expiry on every request, and keep tokens short-lived.

Protect the login itself: limit repeated attempts, and do not reveal whether the username or the password was wrong.

Multi-factor authentication

MFA combines two or more kinds of proof: something you know (password), something you have (phone, security key) or something you are (fingerprint). Phishing-resistant options such as passkeys and security keys are strongest. Offer and encourage MFA for every account.

Do not roll your own crypto

Use established libraries and protocols, keep them updated, and keep keys out of source code. Store keys in a secrets manager or hardware security module for important systems.

Try it yourself

For an app you know, write down: how are passwords stored, how are sessions kept, and what MFA is offered? Mark anything you are unsure about as a question to investigate.

Summary

• Encryption is reversible, hashing is one-way, and signatures prove origin and integrity.
• Store passwords as salted hashes made with Argon2id, scrypt or bcrypt.
• Use secure sessions or short-lived tokens, protect logins, and offer phishing-resistant MFA.