Category: Tools & Setup

Last week I needed an MD5 checksum to verify a file against a vendor’s published manifest. Old habit kicked in: open devtools, reach for the Web Crypto API, type one line. It failed on the spot:

await crypto.subtle.digest('MD5', new TextEncoder().encode('abc'))
// DOMException: Algorithm: Unrecognized name MD5

No MD5. Not deprecated-with-a-warning — just absent, like it was never on the menu. That single rejection is the whole reason HashForge, the in-browser hash generator I keep bookmarked, ships its own MD5 routine instead of asking the browser. Here’s why the browser says no, and how HashForge works around it without uploading your file anywhere.

The Web Crypto API blocks MD5 on purpose

The digest side of the Web Crypto API supports exactly four algorithms: SHA-1, SHA-256, SHA-384, and SHA-512. That list is fixed in the W3C spec. MD5 isn’t missing because nobody filed a ticket — the working group left it out, along with MD4, because shipping a broken hash through an API named “crypto” invites people to misuse it.

MD5 has had practical collision attacks since 2004, when Wang and Yu produced two different inputs with the same digest by hand-tuning the message. By 2008 researchers used MD5 collisions to forge a rogue CA certificate. The hash is finished for anything where an attacker controls the input.

Here’s the part I find funny: the browser still lets you compute SHA-1, which Google and CWI fully collided in 2017 with the SHAttered attack. SHA-1 stayed in the spec for backward compatibility with existing protocols. MD5 never made the cut at all. The vendors drew a line, and MD5 landed on the wrong side of it.

I agree with that call for new code. The catch is that the rest of us still bump into MD5 constantly, and almost never for security:

• Vendor downloads still publish an MD5 next to the file
• S3 ETags are the MD5 of the object for single-part uploads
• Legacy rows store md5(email) for Gravatar-style lookups
• Plenty of internal tools fingerprint content with MD5 because it’s fast and short

So you hit a wall. The data is MD5, the browser refuses to compute MD5, and you would rather not paste a confidential file into some random “free MD5 online” site that ships it off to a server you’ve never audited.

How HashForge fills the gap

HashForge splits the work in two. For the SHA family it calls the native API — fast, audited, hardware-accelerated on most machines:

const ALGOS = ['MD5','SHA-1','SHA-256','SHA-384','SHA-512'];

async function hashText(text, algos, enc='hex'){
  const encoded = new TextEncoder().encode(text);
  const out = {};
  for (const algo of algos){
    if (algo === 'MD5'){
      out[algo] = formatHash(md5(encoded.buffer), enc);     // pure JS
    } else {
      const hash = await crypto.subtle.digest(algo, encoded); // native
      out[algo] = formatHash(hash, enc);
    }
  }
  return out;
}

For MD5 it falls back to a self-contained JavaScript implementation — the classic safeAdd / bitRotateLeft / md5cmn routine you’ve seen in a dozen libraries, working directly on an ArrayBuffer. No dependency, no network call, a couple hundred lines of code.

Why MD5 is small enough to ship inline

MD5 is a Merkle–Damgård construction. It pads the message to a multiple of 512 bits, then chews through it one 512-bit block at a time, updating four 32-bit state words across 64 operations grouped into 4 rounds. The whole thing is integer addition, bit rotation, and a handful of boolean mixing functions. That’s it — no S-boxes, no lookup tables, no big constants beyond a sine-derived table you can generate in one line.

Because the algorithm is so plain, a correct MD5 fits in a few hundred bytes of minified JavaScript. SHA-512 by hand would be heavier and slower in JS, which is exactly why HashForge doesn’t reimplement the SHA family — the native crypto.subtle path is both faster and already vetted. You only drop to hand-rolled code for the one algorithm the platform won’t give you.

The privacy detail that actually matters

Files go through the same split. The page reads the file with file.arrayBuffer() and hands the raw bytes straight to either the native digest or the JS MD5:

const buf  = await file.arrayBuffer();
const hash = await crypto.subtle.digest('SHA-256', buf);

That arrayBuffer() call is the whole privacy story. The bytes are read into memory inside your tab and never touch a network socket. Open the Network panel while you hash a 200 MB ISO and you’ll see zero requests. Pull your wifi and it keeps working, because there was never a server in the loop. Compare that to the typical “online hash calculator,” which POSTs your file to a backend and trusts you to believe their retention policy.

Verify the output yourself in ten seconds

Don’t take my word that the MD5 path is correct — a hash tool that quietly mis-pads is worse than no tool. Hash the empty string and abc, then check against the canonical test vectors:

MD5("")        = d41d8cd98f00b204e9800998ecf8427e
MD5("abc")     = 900150983cd24fb0d6963f7d28e17f72
SHA-256("abc") = ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad

Type abc into HashForge and you’ll get those exact bytes. I cross-checked them against md5sum and sha256sum on a Linux box before trusting the tool with anything real. Two-minute habit, and it catches a surprising number of broken implementations.

HMAC is native-only, and that’s the right limit

One place HashForge refuses to fill a gap: HMAC. It offers HMAC-SHA1/256/384/512 and stops there, because Web Crypto’s importKey plus sign('HMAC', ...) only accepts the SHA family. There’s no HMAC-MD5 button.

That’s correct, not lazy. If you’re computing an HMAC you’re authenticating something, and HMAC-MD5 has no place in new code. The tool steers you to SHA-256 by simply not offering the broken option — the same stance the browser takes on raw MD5, applied one layer up.

Which hash for which job

A quick field guide, because this question comes up every week:

• Matching a published checksum: use whatever the publisher used, MD5 or SHA-256. You’re catching accidental corruption, not an attacker, so a broken hash is fine here.
• Content fingerprint, cache key, dedup: SHA-256 if you have a free choice; MD5 only to match an existing system.
• Passwords: none of these. Use Argon2 or bcrypt. A raw SHA-256 of a password is still a leak waiting to happen.
• Tokens and signatures: HMAC-SHA256 at minimum.

If you want the actual math behind why MD5 fell and SHA-256 holds, Serious Cryptography by Jean-Philippe Aumasson is the clearest book I’ve found on collision attacks without drowning you in proofs. For the engineering side — where each primitive shows up in TLS, signatures, and storage — Real-World Cryptography by David Wong is the one I lend out most. Full disclosure: both are Amazon affiliate links.

Why I keep it bookmarked

The pitch is narrow and that’s the point. I need a hash, I can’t install a CLI on a locked-down work laptop, and I really don’t want to upload a file to a stranger’s server. HashForge does that one job: it computes all five digests at once, outputs hex or Base64, and runs on a text string or a dropped file. It pairs with the other browser-only tools I reach for — Base64Lab when I need to decode a token and PassForge when I need a random key — none of which phone home.

Try it: HashForge. Hash something, open your Network tab, and watch nothing happen.

Join https://t.me/alphasignal822 for free market intelligence.

Last week I was reviewing a small auth service and found this one-liner generating reset tokens:

const token = Array.from({length: 16}, () =>
  CHARS[Math.floor(Math.random() * CHARS.length)]
).join('');

It runs. It produces things like xK9$mLp2@nQ7vR4w. It also happens to be a real security bug. That exact pattern is the one I deliberately avoided when I built our free password generator — and the reason is worth 1,200 words, because almost every “roll your own” password snippet on the web gets it wrong in the same way.

Here’s what’s broken about Math.random() for passwords, the fix, and the two gotchas that bite people who try to fix it themselves.

Math.random() is predictable by design

In V8 — the engine behind Chrome and Node — Math.random() has used an algorithm called xorshift128+ since version 4.9.40, shipped in late 2015. (Before that it was MWC1616, which was worse: only about 2³² possible outputs.) xorshift128+ has 128 bits of internal state, a period of 2¹²⁸ − 1, and it passes the TestU01 statistical suite. Statistically, the numbers look random.

But “looks random” and “unpredictable” are different properties. xorshift128+ is a pseudo-random generator: every output is a deterministic function of that 128-bit state. And the state is recoverable. Feed enough consecutive outputs into a system of linear equations and you can solve for the internal state — there are public tools on GitHub that recover it from as few as 64 to 128 consecutive Math.random() calls. Once an attacker has the state, every future output is known. Every “random” password you generate after that point is predictable.

For a UI animation or a Monte Carlo sim, who cares. For a password, an API key, or a session token, that’s the whole ballgame.

crypto.getRandomValues() is the actual fix

Browsers ship a cryptographically secure RNG (CSPRNG) through the Web Crypto API: crypto.getRandomValues(). It pulls from the operating system’s entropy pool (/dev/urandom on Linux, BCryptGenRandom on Windows) and is built so that observing past output tells you nothing about future output. There’s no recoverable 128-bit state to solve for.

The function our generator uses is four lines:

function secureRandom(max) {
  const arr = new Uint32Array(1);
  crypto.getRandomValues(arr);
  return arr[0] % max;
}

Read a fresh 32-bit unsigned integer from the CSPRNG, reduce it into the range you need, done. Swap Math.random() for this and the prediction attack above is gone. But notice that % max — that’s gotcha number one.

Gotcha 1: modulo bias is real (but size matters)

When you take a random integer modulo your alphabet size, the ranges usually don’t divide evenly, so some characters come up more often than others. I wanted to see how bad it actually is, so I generated 6.2 million random bytes and bucketed byte % 62 (a typical alphanumeric set):

expected per character:  100,000
lowest-frequency char:   ~96,900 hits
highest-frequency char: ~121,400 hits
ratio: 1.25

That’s a 25% skew. It happens because 256 % 62 = 8, so byte values 0–7 each give one extra shot to the first eight characters. With a single byte feeding a 62- or 94-character set, the bias is large and easy to measure.

The textbook fix is rejection sampling: throw away any byte in the biased tail and draw again. Rejecting values ≥ 248 dropped the skew to a 1.02 ratio in my test, at the cost of discarding about 3.1% of draws.

But here’s the part the “always use rejection sampling” advice skips: the bias depends entirely on how big your random integer is relative to the alphabet. Our generator doesn’t read a single byte — it reads a full Uint32 (range 0 to about 4.29 billion). For a 94-character symbol set, Uint32 % 94 makes the favored characters more likely by roughly 1 part in 45 million — a bias of 0.0000022%. For a password, that’s noise far below anything that matters. So I skipped rejection sampling on purpose and kept the code simple, because a 32-bit draw already makes the bias irrelevant. If I were minting cryptographic keys I’d add the rejection step; for human passwords, a wide draw is enough.

Gotcha 2: the 64KB quota wall

The second surprise showed up while I was running that bias test. My first attempt asked getRandomValues() to fill one big buffer:

crypto.getRandomValues(new Uint8Array(620000));
// QuotaExceededError: The requested length exceeds 65,536 bytes

getRandomValues() refuses any request over 65,536 bytes (64 KB) in a single call. It’s in the spec and every browser enforces it. If you’re generating one 16-character password you’ll never hit it, but the moment you batch-generate or fill a large buffer, you have to chunk:

function fillSecure(buf) {
  for (let i = 0; i < buf.length; i += 65536) {
    crypto.getRandomValues(buf.subarray(i, i + 65536));
  }
}

Undocumented in most tutorials, and a hard failure rather than a silent one — which is at least honest of it.

Why browser-only matters here

Our generator runs entirely in your browser. The password is built on your machine from your OS entropy and never touches a network. That’s not a tagline — it’s the only design that makes sense for a secret. A “password generator” that does the work server-side is a service that has seen your password in plaintext, which is the same trust problem I wrote about with online SQL formatters quietly logging queries. Open the dev tools, watch the Network tab while you click generate, and you’ll see exactly zero requests.

You can try it here: the orthogonal.info password generator. Slide to 16+ characters, toggle the symbol set, copy, done.

One layer is never enough

A strong, truly-random password fixes the “guessable” problem. It does nothing about phishing, reused credentials, or a leaked database. After the LastPass mess I moved my own vault into KeePassXC and put a hardware key on every account that supports one. A YubiKey 5 NFC turns a stolen password into a useless string, because login also needs the physical key in my pocket. Full disclosure: that’s an affiliate link — but it’s also literally what’s on my keyring. Generate unique passwords, store them in a real manager, and gate the important accounts with hardware 2FA. Three cheap layers beat one strong one.

The lesson I keep relearning: in security, the code that “works” and the code that’s correct are often the same length and completely different. Math.random() works. crypto.getRandomValues() is correct.

Want signal instead of noise on markets and tech? Join https://t.me/alphasignal822 for free market intelligence.

Last month I watched a contractor paste a full Kubernetes secret manifest — base64 blobs and all — into the first “free YAML validator” that came up on Google. He just wanted to check indentation. What he actually did was POST a production database password to a server he’d never heard of, run by people he’ll never meet, with a privacy policy he didn’t read.

That’s the part of online dev tools nobody talks about. A SQL formatter, a YAML validator, a JSON beautifier — they feel disposable, like a calculator. But a huge number of them send whatever you paste to a backend for processing. If that paste contains a connection string, an API key, or a customer record, you just leaked it. No breach required. You handed it over.

Why “format my SQL” is a data exfiltration path

Here’s the mechanic. Server-side tools work like this: your text goes into a textarea, JavaScript fires an HTTP request to /api/format, the server runs the actual formatting, and the result comes back. Simple to build, which is exactly why so many sites do it that way.

The problem is what travels in that request body. I tested a handful of popular online formatters with my browser’s Network tab open. Several of them sent the entire input payload to their own domain. One sent it to a third-party API. The query I pasted was harmless test data, but the request was real — my text left my machine.

Now picture the realistic version. You’re debugging a failing migration at 11pm. You copy the offending query straight out of your ORM logs to “just clean it up.” That query has a hardcoded credential a teammate left in six months ago. You paste, you format, you move on. The credential is now in someone’s request logs, maybe their analytics, maybe an LLM training pipeline if the tool resells data. You will never know.

This isn’t paranoia. It’s the same threat model that makes pasting code into random pastebins a fireable offense at most security-conscious shops. We just don’t apply it to “format” tools because they feel too small to matter.

The browser-only alternative

The fix is structural, not procedural. Don’t rely on remembering to scrub secrets first — use tools that physically can’t send your data anywhere, because all the work happens in your tab.

That’s the whole reason I built our formatters as single-file, client-side apps. When you use the SQL Formatter, the YAML Validator, or the Diff Checker, the parsing and formatting runs in JavaScript on your device. There is no /api/format endpoint. There’s no backend at all. The text in your textarea never crosses the network, because there’s nowhere for it to go.

For a diff tool this matters even more. People routinely paste two versions of a config file — say, a working .env and a broken one — to spot what changed. Those files are nothing but secrets. A browser-only diff means you can compare two API keys character by character without either one leaving your laptop.

How to actually verify a tool is client-side

Don’t take any tool’s word for it, including mine. Verifying is a two-minute job and every developer should know how.

1. Watch the Network tab. Open DevTools (F12), go to the Network panel, clear it, then paste your text and hit format. If you see a new XHR or fetch request fire with your input in the payload, the tool is server-side. If nothing happens on the network, the work is local.

// What a server-side formatter looks like in Network tab:
POST /api/format-sql
Request Payload: { "query": "SELECT * FROM users WHERE token='sk_live_...'" }

// What a client-side tool looks like:
// (nothing — no request fires when you click format)

2. Kill your connection. The bluntest test there is. Load the page, then turn off Wi-Fi or drop into airplane mode. If the tool still formats your text, it’s running entirely in the browser. If it spins or errors, it needed a server. I do this with any tool before I trust it with anything sensitive.

3. Check for a service worker. Truly offline-capable tools register a service worker so they work with no connection at all. In DevTools, look under Application → Service Workers. Its presence is a strong signal the developer designed for offline-first, which usually means client-side processing too.

Where this fits in a real workflow

A few concrete cases where I reach for browser-only tools specifically because of the data:

• Reviewing a teammate’s config PR. Diffing two Helm values files that contain registry credentials — done locally, nothing logged anywhere.
• Cleaning up a query from prod logs. Format it to read it, without shipping whatever sensitive WHERE clause it carries to a stranger’s server.
• Validating a CI secrets file. Checking that a GitHub Actions YAML parses before you commit, without exposing the encrypted values to a validation API.
• On a locked-down network. Some client environments block external dev-tool domains entirely. Offline-capable tools just keep working.

The broader point: treat every “paste your text here” box as a potential outbound network call until you’ve proven otherwise. Most of the time it’s fine. The one time it isn’t, it’s a leaked credential you can’t un-leak.

Defense in depth still applies

Browser-only tools remove one exfiltration path, but they don’t make you immune to the dumber failure modes — like a secret sitting in your shell history or git log in the first place. If you handle credentials daily, a hardware key cuts a whole class of phishing and credential-theft risk off at the knees. I use a YubiKey 5 Series for exactly this (full disclosure: affiliate link, but it’s the same key I carry on my own keyring). Pair that with the pre-commit secret scanning setup I wrote about earlier, and you’ve closed the two most common ways credentials walk out the door.

Start with the small habit, though. Next time you reach for an online formatter or diff tool, open the Network tab first. If your text leaves the browser, find one that keeps it home.

Join https://t.me/alphasignal822 for free market intelligence.

Last December I got the email every LastPass user dreaded: my vault backup was part of the breach. The master password was strong, but knowing encrypted blobs of my entire digital life were sitting on some attacker’s disk made me physically uncomfortable. I spent a weekend migrating everything to KeePassXC, and six months later I’m not going back.

Why Local-First Matters for Passwords

The LastPass breach exposed a fundamental problem with cloud password managers: your encrypted vault is only as safe as the infrastructure storing it. LastPass used 100,100 PBKDF2 iterations for newer accounts — older accounts had as few as 5,000. That’s crackable with a decent GPU rig.

KeePassXC stores everything in a single .kdbx file on your machine. No servers, no breach notifications, no third-party trust. The file uses AES-256 or ChaCha20 encryption with Argon2d key derivation — you control the iteration count, memory usage, and parallelism. I run mine at 64MB memory / 10 iterations / 4 threads, which takes about 1 second to unlock on my laptop but would cost serious money to brute-force.

The Setup That Actually Works Day-to-Day

The knock against local password managers has always been “but what about sync?” Fair point. Here’s how I solved it without trusting anyone else with my vault:

# My .kdbx lives in a Syncthing folder shared between:
# - Work laptop (Linux)
# - Personal desktop (Windows)
# - Phone (via Syncthing + KeePassDX on Android)

~/.local/share/syncthing/vault/
├── passwords.kdbx
└── passwords.kdbx.key   # key file (separate from master password)

Syncthing handles peer-to-peer sync over my local network and WireGuard tunnel when I’m away. The vault never touches anyone else’s servers. Conflict resolution? KeePassXC handles .kdbx merge conflicts natively since version 2.7 — it’ll prompt you to merge changes if two devices edited simultaneously.

Hardware Key as Second Factor

This is where it gets good. KeePassXC supports YubiKey challenge-response as an additional key factor. My unlock requires:

1. Master password (memorized, 6 random words)
2. Key file (stored only on my devices, never synced to cloud)
3. YubiKey HMAC-SHA1 challenge-response (slot 2)

Setting this up:

# Program YubiKey slot 2 for HMAC-SHA1 challenge-response
ykman otp chalresp --generate 2

# In KeePassXC: Database → Database Security → Add Additional Protection
# Select "Challenge-Response" → pick your YubiKey

An attacker who steals my .kdbx file needs all three factors. Even if they get my laptop with the key file, they still need the physical YubiKey and the password. I keep a backup YubiKey 5 NFC in my safe — $50 for peace of mind that I won’t lock myself out.

Browser Integration Without the Extension Tax

KeePassXC’s browser integration works through a native messaging host — no network calls, no cloud sync of browser state. I tested fill speed across three setups:

KeePassXC fills faster because it communicates through a Unix socket to the running desktop app — no HTTP round-trips, no extension JavaScript parsing the DOM. The browser add-on is just a thin UI layer.

# Enable browser integration (Linux)
# KeePassXC → Tools → Settings → Browser Integration
# Check "Enable browser integration"
# Check "Firefox" and/or "Chromium"
# It writes the native messaging manifest automatically to:
# ~/.mozilla/native-messaging-hosts/org.keepassxc.keepassxc_browser.json

Honest Comparison: KeePassXC vs The Cloud Options

vs Bitwarden — Bitwarden is the closest competitor and genuinely good. It’s open source, self-hostable (Vaultwarden), and the free tier is generous. I’d recommend it to anyone who doesn’t want to manage sync themselves. The tradeoff: you’re trusting their server-side encryption implementation, or running your own server (which means patching, backups, certificates). KeePassXC has no server component to maintain or secure.

vs 1Password — Polished UI, great team features, expensive ($36/year individual, $60/year family). The “Secret Key” system is clever — it means 1Password can’t decrypt your vault even with a breach. But it’s closed source. You’re trusting their claims. For a solo developer who reads source code, that’s a non-starter for me.

vs LastPass — Just don’t. After the 2022 breach, the 2023 follow-up showing employee vaults were compromised, and the consistently slow response times… there’s no reason to trust them with anything sensitive.

The One Thing That Annoys Me

Mobile is worse than cloud managers. Full stop. KeePassDX on Android works, but auto-fill is flaky on some apps, and you need to manually trigger sync if you added a password on desktop 30 seconds ago. I’ve accepted this tradeoff — I add most passwords on desktop anyway, and the security model is worth the occasional inconvenience on mobile.

Migration Script

If you’re coming from LastPass, Bitwarden, or 1Password, KeePassXC imports CSV exports directly. Here’s my cleanup script that runs after import to organize entries:

#!/usr/bin/env python3
"""Post-import cleanup for KeePassXC CSV import.
Removes duplicate entries and normalizes URLs."""
import csv, sys
from urllib.parse import urlparse

def normalize_url(url):
    parsed = urlparse(url)
    return f"{parsed.scheme}://{parsed.netloc}".lower()

seen = {}
with open(sys.argv[1]) as f:
    reader = csv.DictReader(f)
    for row in reader:
        key = (row['Username'], normalize_url(row.get('URL','')))
        if key not in seen or len(row.get('Password','')) > len(seen[key].get('Password','')):
            seen[key] = row

print(f"Deduplicated: {len(seen)} unique entries")

My Recommendation

If you’re a developer comfortable with file management and want zero cloud trust for your passwords: KeePassXC + Syncthing + YubiKey is the strongest setup I’ve found. Total cost: $50 for the YubiKey (plus a backup), everything else is free and open source.

If you want something that “just works” across devices without any setup: Bitwarden free tier. No shame in that — it’s genuinely good software.

For more tools and privacy-focused workflows, check out our security guides and tools section.

Full disclosure: Amazon links above are affiliate links (tag=orthogonalinf-20). I bought my YubiKeys at full price before writing this.

📡 Join https://t.me/alphasignal822 for free market intelligence — we cover fintech security and trading tools daily.

Last month I locked myself out of my GitHub account. Again. My TOTP app had synced to a new phone but silently dropped three seeds during the transfer. That was the third time in two years I’d lost access to something important because of software-based 2FA. I ordered a YubiKey 5 NFC that afternoon.

Six weeks later, every account I care about uses FIDO2/WebAuthn hardware authentication. No more six-digit codes. No more seed backups. No more “did my authenticator app actually sync?” anxiety. Here’s what the transition actually looks like — the good parts and the frustrating ones.

Why Software 2FA Keeps Failing

TOTP (those six-digit rotating codes) has a fundamental problem: the secret is just a string that lives on your phone. Phone dies? Secret’s gone. Switch phones? Hope your backup worked. Get phished? An attacker with your password and your current TOTP code has everything they need — and phishing proxies like Evilginx2 automate this in real time.

FIDO2 hardware keys solve this differently. The private key never leaves the physical device. Authentication uses a challenge-response protocol tied to the specific domain — so even if you click a perfect phishing link to g00gle.com, the key won’t respond because the domain doesn’t match. It’s not just a second factor; it’s phishing-proof by design.

I tested this myself. I set up a fake login page on my local network and tried to authenticate with my YubiKey. Nothing happened. The browser prompted me, I tapped the key, and it simply refused. With TOTP, I would have typed the code without thinking.

The Hardware: YubiKey 5 NFC vs. the Alternatives

I went with the YubiKey 5 NFC (USB-A) as my primary and a YubiKey 5C NFC (USB-C) as backup. You always want two keys — if you lose one, the backup gets you back in. Full disclosure: affiliate links.

Here’s how the main options compare:

• YubiKey 5 NFC (~$50) — supports FIDO2, U2F, smart card (PIV), OpenPGP, OTP. Works with USB-A and NFC on phones. The Swiss Army knife option. I’ve been using mine daily for six weeks with zero issues.
• Google Titan Security Key (~$30) — FIDO2 and U2F only. No smart card, no OpenPGP. Cheaper, but if you want to sign Git commits or use SSH keys on the hardware, you’re stuck.
• SoloKeys Solo 2 (~$30) — open-source firmware, FIDO2 only. Great if you want to audit the code yourself. Limited protocol support compared to YubiKey.
• Nitrokey 3 (~$50) — open-source, supports FIDO2, OpenPGP, PIV. Solid open-source alternative to YubiKey, though firmware updates have historically been slower.

I picked YubiKey because of the protocol breadth. I use FIDO2 for web logins, PIV for SSH, and OpenPGP for Git commit signing — all on one device. If you only need web authentication, the Titan or Solo 2 will save you $20.

Setting Up FIDO2 on Everything That Matters

The registration process is the same everywhere: go to security settings, choose “Security Key,” tap your YubiKey when prompted, done. But the details vary enough to be annoying.

GitHub — smooth. Settings → Password and authentication → Security keys. Register both keys (primary + backup). Took 2 minutes. GitHub also supports using the key for git push verification via SSH resident keys:

ssh-keygen -t ed25519-sk -O resident -O application=ssh:github
# Tap YubiKey when it blinks
# Upload the .pub to GitHub SSH keys

Now every git push requires a physical tap. No one’s pushing to my repos from a compromised machine.

Google — also smooth, but with a catch. You need to enroll in Google’s Advanced Protection Program to get the full benefit. Without it, Google still allows fallback to SMS or TOTP, which defeats the purpose. With Advanced Protection, only hardware keys work. Period.

AWS — this one frustrated me. AWS IAM supports FIDO2 for root accounts and IAM users, but the console registration flow is finicky. I had to use Chrome (Firefox didn’t trigger the WebAuthn prompt correctly in May 2026). Once registered, it works reliably.

Cloudflare — perfect support. They use hardware keys internally and it shows. Registration took 30 seconds.

SSH Authentication Without Software Keys

This is where things get interesting for developers. Instead of keeping an ed25519 private key in ~/.ssh/, you can generate a resident key that lives on the YubiKey itself:

# Generate a resident SSH key on the YubiKey
ssh-keygen -t ed25519-sk -O resident -O verify-required

# Load it from the key (works on any machine with the YubiKey plugged in)
ssh-add -K

# Check it's loaded
ssh-add -L

The -O verify-required flag means you need to enter the YubiKey’s PIN and tap it for each SSH connection. Paranoid? Yes. But it means even if someone steals your unlocked laptop, they can’t SSH anywhere without the physical key and the PIN.

I use this for all my homelab connections. My TrueNAS server, my development VMs, my remote build machines — all require the YubiKey tap. The ~/.ssh/ directory on my laptop has exactly zero private key files in it now.

The Annoying Parts (Because Nothing Is Perfect)

I won’t pretend this is all smooth sailing. Some real friction points:

• Mobile is awkward. NFC works on Android and iOS, but you have to hold the key against the right spot on your phone. On my Pixel 8, the NFC reader is in the center-back. On iPhones, it’s at the top. Every login on mobile involves an awkward fumble.
• Not everything supports FIDO2. My bank doesn’t. My health insurance portal doesn’t. Some services technically support it but bury the option so deep you’d never find it without documentation.
• Two keys minimum is expensive. At $50 each, you’re spending $100+ before you’ve protected a single account. Compared to free authenticator apps, that’s a tough sell for people who haven’t been burned yet.
• Recovery codes are still important. If you lose both keys (fire, theft), you need recovery codes. I print mine and keep them in a fireproof safe. It’s not elegant but it works.

What Changed After Six Weeks

The biggest surprise wasn’t security — it was speed. Tapping a key takes about 0.5 seconds. Pulling up an authenticator app, finding the right account, and typing six digits takes 10-15 seconds. Over dozens of logins per week, that adds up.

I also stopped worrying about phone transfers. My YubiKey doesn’t care what phone I’m using. It doesn’t sync anywhere. It doesn’t need a backup. It’s just a piece of hardware on my keyring.

For developers specifically: the SSH resident key feature alone is worth the price. Not having private keys on disk removes an entire attack surface. Combined with a good laptop lock for when you’re at a coffee shop, your attack surface shrinks significantly.

If you’re still using TOTP and haven’t been burned yet — you will be. It’s not a question of if, it’s when. A YubiKey 5 NFC and a backup key is the best $100 I’ve spent on security tooling this year.

For more on security and developer workflows, check out our DevSecOps guide and homelab security guide.

Join Alpha Signal on Telegram for free market intelligence — including weekly picks on security and infrastructure companies worth watching.