What is PBKDF2 Encryption? A Plain-English Guide

The Acronym Everyone Mentions but Nobody Explains

If you've ever read the description of a password manager or a security tool, you've probably seen something like "secured with PBKDF2 encryption, 600,000 iterations." It sounds impressive, important, and completely impenetrable — in the sense that you have no idea what it means.

Here's the thing: you don't need a computer science degree to understand this. The core idea is surprisingly simple, and once you get it, you'll be able to evaluate security claims like a pro.

Passwords Have a Fundamental Problem

When you type a password into a website or an app, that password needs to be stored somewhere so the system can check if you typed the right one next time. But storing the actual password is a terrible idea — if the database gets hacked, every user's password is exposed in plain text.

So instead, passwords are hashed. Hashing is a one-way mathematical function that turns your password into a string of random-looking characters. "MyDogMax2026" becomes something like a4f2c88b9e3d.... The key property is that you can go from password → hash easily, but going from hash → password is practically impossible.

At least, that's how it's supposed to work.

Why Basic Hashing Isn't Enough Anymore

Modern computers are frighteningly fast. A standard hashing algorithm like SHA-256 can compute billions of hashes per second. That means an attacker who steals a database of hashed passwords can simply try every possible password combination at incredible speed and see which one produces a matching hash.

This is called a brute-force attack, and against basic hashing, it works disturbingly well. A simple 6-character password can be cracked in seconds. Even an 8-character password might fall in hours.

This is where PBKDF2 enters the picture.

PBKDF2: Making Hashing Deliberately Slow

PBKDF2 stands for Password-Based Key Derivation Function 2. The name is a mouthful, but the concept is elegant: it takes regular hashing and makes it intentionally, computationally expensive.

Instead of hashing your password once, PBKDF2 hashes it hundreds of thousands of times in a row. Each hash feeds into the next, creating a chain of computation that takes real, measurable time.

Here's the analogy I like best: imagine a regular lock that can be picked in one second. Now imagine a lock where, to pick it, you have to pick it 600,000 times in sequence, and each pick resets every other lock. That's PBKDF2.

For a legitimate user typing their correct password, this process takes about 100 milliseconds — completely imperceptible. You enter your password, the system runs 600,000 iterations in a tenth of a second, and you're in.

But for an attacker trying to brute-force their way through millions of passwords? Each guess now takes 100ms instead of nanoseconds. That turns a hours-long attack into one that would take centuries.

The Iterations Number Actually Matters

When you see "600,000 iterations," that's the number of times PBKDF2 runs the hashing function for a single password verification. This number matters a lot:

• 1,000 iterations (used in early 2000s): Crackable with modern hardware
• 100,000 iterations: Better, but GPUs are fast
• 600,000 iterations (OWASP recommended in 2023+): Current security standard
• 1,000,000+ iterations: Maximum security, slightly slower verification

Locksy uses 600,000+ iterations, which is the current recommendation from OWASP (the Open Web Application Security Project). It's the sweet spot between security and user experience — strong enough to stop any practical brute-force attack, fast enough that you never notice a delay.

What About Salt?

There's one more important ingredient: salt. No, not the table kind.

A salt is a random string of data that's unique to each user and gets mixed in with the password before hashing. Without salt, two users with the same password would produce the same hash — which means an attacker could pre-compute a giant table of common password hashes (called a "rainbow table") and just look up matches.

Salt makes rainbow tables useless. Even if two people both use "password123" (please don't), their hashes will be completely different because each one has a unique salt mixed in.

How This Protects Your Locked Tabs

When you set a master password in a tab-locking extension like Locksy, here's what actually happens behind the scenes:

1. You type your password
2. A random salt is generated (unique to your installation)
3. PBKDF2 runs your password + salt through 600,000+ iterations of SHA-256
4. The result is your encryption key — used to lock and unlock your tabs
5. Your actual password is never stored anywhere

When you unlock a tab, the same process runs in reverse: your password + stored salt → 600,000 iterations → key → decrypt and show the tab.

If someone tries to guess your password, they have to run all 600,000 iterations for every single guess. And with rate limiting on top (where each failed attempt adds increasingly long delays), brute-force attacks become not just impractical but mathematically absurd.

PBKDF2 vs. bcrypt vs. Argon2

If you're curious how PBKDF2 compares to other password hashing algorithms:

bcrypt is another widely used algorithm that's also intentionally slow. It was designed specifically for password hashing and has been battle-tested since 1999. It's great, but it processes passwords in 72-byte chunks, which can silently truncate very long passwords.

Argon2 is the newest of the three, and won the Password Hashing Competition in 2015. Its advantage is that it's designed to resist not just CPU-based attacks but also GPU and specialized hardware attacks, by requiring a configurable amount of memory.

All three are solid choices. PBKDF2's advantage is its ubiquity and proven track record — it's been in widespread use since 2000, it's included in most programming platforms by default, and it's been reviewed and recommended by organizations like NIST, OWASP, and the IETF.

For browser extensions specifically, PBKDF2 is the practical choice because it works efficiently in JavaScript (the language browsers speak) through the Web Crypto API, without requiring any external dependencies.

What "Encryption" Actually Means in Context

Worth clarifying: PBKDF2 itself isn't encryption. It's key derivation — it turns your password into a key. That key is then used with an actual encryption algorithm (typically AES-256) to encrypt and decrypt your data.

Think of it this way: PBKDF2 is how you forge the key, AES is the lock that key operates. Both are essential, but they do different jobs.

How to Evaluate Security Claims

Next time a tool tells you it uses "military-grade encryption" or "bank-level security," here's your checklist:

1. Do they specify the algorithm? PBKDF2, bcrypt, or Argon2 are all legitimate. "Proprietary encryption" is a red flag.
2. What's the iteration count? For PBKDF2, 600,000+ is the current standard.
3. Is it open source? Can you verify the claims by reading the code?
4. Where is data processed? Locally on your device is ideal. Server-side means your data travels over the internet.
5. Is there rate limiting? Even the best encryption means nothing if you can guess unlimited passwords per second.

If a tool checks all five boxes, you're in good shape.

The Takeaway

PBKDF2 takes a fundamentally simple idea — hash the password many, many times — and turns it into a practical, proven defense against the most common form of password attack. It's not magic. It's math. And it's the reason your locked tabs are actually safe, not just hidden behind a pretty lock screen.

Locksy uses PBKDF2 with 600,000+ iterations, open-source code, and zero server communication. See for yourself on GitHub.