DEV Community: Mike Knights

The padlock doesn't mean what you think it means

Mike Knights — Wed, 27 May 2026 09:22:01 +0000

Everyone knows the padlock in the browser address bar means the site is "secure". But secure in what sense? Most people assume it means the site is trustworthy. It doesn't. It means the connection is encrypted. Those are very different things.

A phishing site can have a padlock. A site stealing your credit card details can have a padlock. The padlock tells you nobody is intercepting the traffic between your browser and the server - it says nothing about what the server itself does with your data.

So what does HTTPS actually do?

It wraps HTTP traffic in TLS (Transport Layer Security), encrypting everything in both directions. Your request, the response, the cookies, the headers - all of it. Without HTTPS, anyone on the same network can read it in plain text.

Three things HTTPS gives you:

Encryption - nobody in the middle can read the traffic
Integrity - nobody in the middle can tamper with it without detection
Authentication - the certificate verifies you're talking to the actual server, not an impersonator

The handshake

Before any HTTP data flows, the browser and server do a TLS handshake. In TLS 1.3 (the current version) this takes one round trip:

Browser sends supported cipher suites and a random value
Server sends its certificate and picks a cipher suite
Browser verifies the certificate against a trusted Certificate Authority
Both sides derive a shared session key using Diffie-Hellman - without ever sending the key itself across the network
Encrypted traffic begins

The clever bit is step 4. Asymmetric encryption (slow, uses public/private key pairs) is only used to establish the shared secret. After that, symmetric encryption (fast, single shared key) handles the actual data. You get the security of asymmetric with the speed of symmetric.

What certificates actually prove

A TLS certificate contains the server's public key and a signature from a Certificate Authority (CA) - an organisation your browser already trusts. The CA has verified the domain owner controls the domain before signing.

When your browser sees the certificate, it checks the CA signature. Valid signature from a trusted CA = the certificate is legitimate. This is why self-signed certificates get a browser warning - there's no trusted third party vouching for them.

SSL is dead, TLS is what you're using

When people say "SSL certificate" they mean TLS certificate. SSL 2.0 and 3.0 are deprecated and broken. TLS 1.0 and 1.1 are disabled in modern browsers. TLS 1.2 is still around but being phased out. TLS 1.3 is what you want - it dropped several legacy features that had caused vulnerabilities in older versions.

What HTTPS doesn't protect

The domain name - the hostname you're connecting to is visible in DNS lookups and in the SNI field of the TLS handshake, even over HTTPS
The server itself - once data arrives at the server, HTTPS is done. If the server stores passwords in plain text, HTTPS didn't help
Your device - malware that intercepts traffic before it's encrypted bypasses HTTPS entirely

The padlock is meaningful. It's just not the whole story.

For a more detailed breakdown of the handshake steps and the SSL/TLS version history, datatoolkit.net/learn/how-does-https-work covers it. SHA-256 - the hash algorithm used in TLS certificate signatures - can be tested at datatoolkit.net/sha256.

Base64 is not encryption - here's what it actually does

Mike Knights — Thu, 14 May 2026 08:49:20 +0000

Base64 comes up constantly - in JWTs, email attachments, data URIs, API payloads. Most developers have used it dozens of times. But a surprising number have a slightly wrong mental model, and that leads to misuse.

The biggest mistake: treating it as a form of obfuscation or lightweight encryption. It isn't.

What it actually does

Base64 takes binary data and converts it into a string of 64 printable ASCII characters (A-Z, a-z, 0-9, +, /). The original data is completely recoverable with no key required. Anyone who sees the output can decode it in seconds.

The reason it exists has nothing to do with security. Many systems that transport text - email, HTTP headers, JSON, HTML attributes - were never designed to handle arbitrary binary data. If you embed raw binary in those systems, you get corruption or parsing errors. Base64 gives binary a safe disguise for the journey.

Where you run into it

JWTs. A JSON Web Token is three Base64url-encoded sections separated by dots. The header and payload are just encoded JSON - paste either into a Base64 decoder and you can read them in plain text. The only security comes from the signature at the end, not the encoding. Don't put sensitive data in a JWT payload unless you're encrypting it separately.

HTTP Basic Auth. The Authorization: Basic header is username:password Base64-encoded. It looks obscure, but it isn't. HTTPS is what protects it in transit.

Data URIs. data:image/png;base64,... in HTML or CSS is the image file encoded inline. Fine for small icons, bad idea for anything large.

Email attachments. SMTP was built for plain text. Attachments are Base64-encoded inside the message body so binary files survive.

The padding thing

The = characters at the end aren't significant - they're padding to make the output length a multiple of 4. Base64url (used in JWTs and URLs) drops the padding entirely and replaces + with - and / with _ so the output is URL-safe. Same data, different alphabet.

When to use it

When you need to move binary data through a system that only speaks text. That's it. Not for hiding data, not for security, not as a step in encryption (unless you're encoding the output of actual encryption).

If you want to encode or decode something quickly in the browser - nothing leaves your device - datatoolkit.net/base64 does it client-side. There's also a longer explanation of how the encoding works mechanically if you want the full picture.

MD5 is broken - here is what to use instead

Mike Knights — Fri, 08 May 2026 09:34:09 +0000

MD5 is everywhere. It is in legacy codebases, old tutorials, and still used by developers who have not stopped to check whether it is still appropriate. In most cases it is not.

Here is a clear breakdown of what hash functions are, why MD5 is broken, and what you should use instead.

What is a hash function?

A hash function takes any input - a word, a file, an entire database dump - and produces a fixed-length string called a hash or digest. The same input always produces the same hash. Change even one character and the output changes completely.

SHA-256("hello")  = 2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824
SHA-256("hello!") = ce06092fb948d9ffac7d1a376e404b26b7575bcc11ee05a4615fef4fec3a308b

This "tiny input, wildly different output" property is the avalanche effect and is fundamental to why hash functions are useful.

Hash functions are one-way. You cannot reverse a hash back to the original input. This makes them useful for verifying data without storing the data itself.

The algorithms compared

Algorithm	Output	Status	Use today?
MD5	128-bit / 32 chars	Broken	Checksums only - never security
SHA-1	160-bit / 40 chars	Broken	Legacy only - avoid
SHA-256	256-bit / 64 chars	Secure	Yes - general purpose
SHA-512	512-bit / 128 chars	Secure	Yes - where extra strength is needed

Why is MD5 broken?

A hash function is considered broken when researchers can produce a collision - two different inputs that produce the same hash output.

MD5 collisions can be generated in seconds on consumer hardware. Researchers have demonstrated collision attacks that produce two entirely different files with the same MD5 hash. SHA-1 was formally broken in 2017 with the SHAttered attack.

SHA-256 has no known practical collisions. Its 256-bit output space is so vast that even with all the computing power on Earth, brute-forcing a collision would take longer than the age of the universe.

What is MD5 still acceptable for?

MD5 is still fine when:

You need a fast, non-cryptographic checksum to detect accidental corruption (not adversarial tampering)
You are checking whether a cached resource has changed
The context has no security implications whatsoever

MD5 is not acceptable for:

Password hashing (use bcrypt or Argon2 - not any raw hash function)
File integrity verification where tampering is a concern
Digital signatures
Any security-sensitive context

What should you use?

For file integrity / checksums: SHA-256. It is fast enough for almost all use cases and is the standard for software distribution (you see it on download pages as the verification hash).

For password storage: Never use a raw hash function. Use bcrypt, Argon2id, or scrypt. These are purpose-built password hashing algorithms that are deliberately slow and include salting. See How Passwords Are Hashed for the full explanation.

For HMAC / API signing: SHA-256 via HMAC (HMAC-SHA256).

For digital signatures: SHA-256 (part of RSA-SHA256 and ECDSA-SHA256).

Generate hashes online

You can generate MD5, SHA-1, SHA-256, and SHA-512 hashes instantly in your browser - nothing is sent to any server - at:

For a broader explanation of how hash functions work, see What Is a Hash Function?

TL;DR

MD5 and SHA-1 are cryptographically broken - collisions can be generated deliberately
Use SHA-256 for checksums, file integrity, HMAC, and signatures
Never use any raw hash for passwords - use bcrypt or Argon2id
SHA-256 has no known practical collisions and is the current standard

Stop using UUID v4 as your database primary key

Mike Knights — Fri, 08 May 2026 09:31:07 +0000

I spent a while wondering why inserts on a particular table were getting slower as it grew. The table had a UUID v4 primary key and a few indexes. The data wasn't huge - a few million rows - but write performance was noticeably degrading.

The problem wasn't the query. It was the UUID.

What's actually happening

UUID v4 is random by design. Every new ID lands at a completely unpredictable position in the B-tree index. So every insert causes the database to find that random position, potentially split a page to make room, and rebalance. Do this millions of times and you end up with a fragmented index, lots of wasted space, and slower writes.

With an auto-incrementing integer, every new row goes at the end. No splits. No rebalancing. The index stays tight.

UUID v4 throws all of that away.

UUID v7 fixes it

UUID v7 was standardised in RFC 9562 (May 2024). The important bit: the first 48 bits are a Unix millisecond timestamp. Because time only moves forward, v7 UUIDs sort chronologically - new ones are always greater than old ones.

The database sees the same sequential insertion pattern it gets from an integer primary key. No fragmentation. You keep all the benefits of a UUID (globally unique, no central registry, works across distributed systems) without the index penalty.

It looks identical to v4:

018f6e3a-2b4c-7d8e-9f0a-1b2c3d4e5f6a

Drop-in replacement. Same format, same length.

When v4 is still the right call

If the ID is exposed publicly and you don't want to leak when a record was created - use v4. The timestamp in v7 is extractable, which can be a privacy concern for things like user account IDs.

For internal records, order IDs, event logs, anything where sequential ordering is fine - v7.

Language support

Most stacks have it now. Node.js uuid package has uuid.v7() since v9. Python 3.14 has it in stdlib, or use the uuid7 package. ramsey/uuid in PHP, google/uuid in Go, Prisma has uuid(7) as a default option. PostgreSQL has the pg_uuidv7 extension.

If you're starting a new project, just use v7. If you have an existing table with v4, you don't need to migrate - new rows can switch immediately and the index tightens up gradually as old pages get rewritten.

For generating both versions with various formatting options, datatoolkit.net/uuid does the job. There's also a more detailed writeup on the performance implications at datatoolkit.net/learn/uuid-v4-vs-v7.