13 Attacks, 0 Vulnerabilities: Building a Security Toolkit With Zero Dependencies, ZeroVault

Aaditya2010-14 — Wed, 09 Sep 2026 12:47:02 +0000

TL;DR : I built a complete security toolkit (encrypted vault, TOTP authenticator, file encryptor, git secrets scanner, QR code generator, and a self-testing penetration suite) using nothing but Go's standard library. 82 files, 115 tests, 22 stdlib substitutions, zero packages. It then ran 13 automated attacks against itself and passed every one. Full source and demo at the bottom.

First, what's a "zero-dependency" project and why does anyone care?

Every time you run go get, npm install, or pip install, you're trusting someone else's code with your application. That sounds fine until you see the numbers:

454,600 malicious packages were uploaded to registries last year alone
The average Node.js project has 683 transitive dependencies
One compromised package in your tree and your users' data is exposed

For security tools specifically, this is ironic. The software you trust to protect your passwords is itself trusting hundreds of packages you've never audited.

So a hackathon called Zero Dependency asked a simple, slightly rebellious question:

What if you built something genuinely useful using **nothing but the language itself?

No packages. No go get. Just Go's standard library. I said yes. Solo. Here's what happened.

What I built: ZeroVault, a security toolkit that ships as one binary

ZeroVault is everything you'd normally need three or four packages to build, packed into a single binary with an empty go.mod:

Encrypted password vault — AES-256-GCM encryption, PBKDF2 key derivation with 100,000 iterations
TOTP 2FA generator — RFC 6238 compatible, verified byte-for-byte against Google Authenticator
File encryption/decryption — streaming AES-GCM in 64KB chunks, handles files of any size
Secrets scanner — regex pattern matching + Shannon entropy analysis, scans current files AND git commit history by reading .git/objects directly
Password health dashboard — strength scoring, reuse detection, offline breach checking against 500 known compromised passwords
QR code generation — implemented from the ISO 18004 specification, Reed-Solomon and all
Vault 2FA — the vault protects itself using its own TOTP implementation
Clipboard auto-clear — passwords vanish from clipboard after 10 seconds
Web dashboard — premium UI with CSRF protection, XSS prevention, security headers, rate limiting
Automated penetration test suite — 13 real attacks with HTML audit report export
One-command demo mode — zerovault demo sets up everything for judges to try in 10 seconds

How you'd normally build this: go get a crypto library, a TOTP package, a web framework, a CSRF middleware, a QR encoder, a git library. Six dependencies minimum, each with their own dependency trees.

How I built it: composed crypto/aes, crypto/cipher, crypto/hmac, net/http, html/template, compress/zlib, regexp, and math from Go's standard library.

The proof:

$ cat go.mod
module zerovault

go 1.27

$ go list -m all
zerovault

That's it. That's the entire supply chain. One line: my own code.

The fun part: what I'd normally install, and what replaced it

This is the heart of the story. For each thing I needed, here's the package I'd usually grab, and the standard-library feature I used instead.

1. truffleHog → reading git's internals with compress/zlib

Normally I'd install: trufflesecurity/trufflehog (scans git history for leaked secrets)

What it actually takes: Git objects are just zlib-compressed files sitting in .git/objects/. The format is documented and surprisingly simple:

A commit object contains a tree hash, parent hash, author, and message
A tree object contains file entries: mode, name, and blob hash
A blob is the raw file content

I read them with compress/zlib, parsed the internal format with bytes and encoding/hex, and walked the commit graph backwards through parent hashes. When the scanner finds an AWS key in a blob that was deleted three commits ago, it reports: "deleted but still in history."

That's the exact feature people install truffleHog for. It took about 200 lines of stdlib Go. No git binary needed, no shelling out, no library. Just compress/zlib and string parsing.

The moment this worked, scanning a test repo and finding a Stripe key that had been "deleted" two commits prior — was probably the most satisfying moment of the entire hackathon.

2. pquerna/otp → TOTP in ~15 lines of HMAC

Normally I'd install: pquerna/otp or xlzd/gotp (TOTP/HOTP generation)

What it actually takes: Read RFC 6238. The entire TOTP algorithm is:

1. T = floor(unix_time / 30)
2. T_bytes = T as 8-byte big-endian
3. mac = HMAC-SHA1(secret, T_bytes)
4. offset = mac[19] & 0x0F
5. code = (mac[offset:offset+4] as uint32) & 0x7FFFFFFF
6. code = code % 1,000,000
7. Zero-pad to 6 digits

Go's stdlib has crypto/hmac, crypto/sha1, encoding/binary, and encoding/base32. Compose them exactly as the RFC says. The output matches Google Authenticator.

But here's where it gets meta: after building TOTP, I used it to protect the vault itself. zerovault 2fa enable generates a TOTP secret for the vault, and now unlocking requires both a master password AND a 6-digit code from your phone. I didn't install a 2FA library for the vault, I reused the TOTP code I'd already written.

Eating your own cooking. Zero additional lines of crypto.

3. gorilla/csrf → one line of stdlib

Normally I'd install: gorilla/csrf (CSRF protection middleware)

What it actually takes: Go 1.25 added CrossOriginProtection directly to net/http. It blocks cross-origin POST requests by checking the Origin header, the same approach gorilla/csrf uses internally.

One line to enable it. CSRF handled.

Combined with html/template (which auto-escapes dynamic content against XSS by default) and manually setting security headers (X-Frame-Options, CSP, no-cache), the entire web security layer came from stdlib. No middleware packages.

I verified this with automated tests: a curl POST with Origin: http://evil-site.com gets 403'd. The same request from localhost:8080 succeeds. The XSS tests inject <script>alert('hacked')</script> as a username, it renders as literal text in the browser. 8 different XSS payloads, all neutralized by html/template's auto-escaping.

4. QR code generation → math and patience

Normally I'd install: skip2/go-qrcode or any QR generation library

What it actually takes: This was the hardest single feature. QR codes involve:

Data encoding — numeric, alphanumeric, and byte modes with different bit lengths
Error correction — Reed-Solomon codes over GF(256), which means implementing Galois field arithmetic: addition (XOR), multiplication (log/antilog tables), polynomial division
Module placement — a specific pattern of data, error correction, format info, timing patterns, and alignment patterns
Masking — 8 different mask patterns, each scored for readability, pick the best one

I implemented all of it from the ISO/IEC 18004 specification. The GF(256) math alone — building the log/antilog lookup tables, computing generator polynomials, dividing data polynomials by generator polynomials — took real effort.

But when I ran zerovault totp qr github-2fa and Google Authenticator on my phone actually scanned the terminal output and added the account correctly, that was the single best moment of the hackathon.

No image library. No QR library. Just math, fmt, and stubbornness.

5. Password managers & breach databases → crypto/sha256 + embedded hashes

Normally I'd install: Something like a haveibeenpwned client or a breach database package

What it actually takes: I embedded the SHA-256 hashes of 500 commonly breached passwords directly in the source code. Not the passwords themselves, just their hashes. On every health check, each stored password is hashed and compared against the set.

"password123" → SHA-256 → check against embedded set → 
MATCH → "⚠ appears in breach databases"

Completely offline. No API calls. No internet. No dependency. The health dashboard shows a breach warning as a red banner that's impossible to miss.

The bug that almost killed my demo

During a hardening pass near the end, I ran go build -race and the race detector found something real.

The problem: Two concurrent HTTP requests could trigger simultaneous vault saves. On Windows, os.Rename (used for atomic file writes, write to temp file, rename over the original) doesn't behave atomically when the target file is open by another goroutine. The race detector caught it under a 60-request stress test.

How I found it: I almost didn't. The race only surfaces under concurrent web requests, my manual testing was always single-user. If I hadn't run the race detector as part of a systematic hardening pass, this would have surfaced live during the demo as a crash.

The fix: A per-session mutex held for the duration of each handler, plus unique temporary filenames per write operation (using a counter instead of a fixed name). The race detector confirmed the fix was clean.

The lesson: go build -race is not optional for concurrent Go code. This is the kind of bug a team of four catches in code review. Solo, the tooling has to catch it for you.

The attack suite: a security tool that tests itself

This is the feature I'm most proud of, and the one no other hackathon team built.

zerovault attack runs 13 automated penetration tests against the running application:

Crypto attacks:

Dictionary brute force — tries 20 common passwords, each takes ~0.3 seconds (PBKDF2 doing its job)
Vault bit-flip tampering — flips bits at 5 positions, GCM catches every one
Vault truncation/injection — tries appending, truncating, stripping the auth tag
PBKDF2 timing analysis — verifies no timing side-channel across password lengths
Nonce reuse detection — saves the vault 100 times, verifies all nonces are unique

Web attacks:

XSS injection — 8 different payloads (script tags, img onerror, SVG, template injection)
CSRF — 5 fake origins including null and wrong-port
Session security — no-cookie access, fake cookies, expired sessions, post-lock reuse
Security headers — verifies X-Frame-Options, CSP, nosniff, no-cache
Path traversal — tries ../../../etc/passwd and system directories on the scanner

TOTP attacks:

Code brute force — documents that TOTP security comes from the secret, not the code

The output is a terminal scoreboard AND a self-contained HTML audit report:

RESULTS: 10 blocked | 2 secure | 1 expected | 0 vulnerabilities

The attack scripts themselves are real code, attacks/bruteforce.go contains actual PBKDF2 derivation loops, attacks/xss.go sends real HTTP requests with real payloads and checks the response HTML for unescaped tags. I showed the source code in the demo video before running the suite so judges could see it wasn't fake output.

What the stdlib made painful

No argon2, no bcrypt, no scrypt

All three live in golang.org/x/crypto. Not stdlib. Can't use them.

PBKDF2 with 100,000 iterations is the OWASP minimum, and it's what I used. Is it as good as argon2? No, argon2 is memory-hard, which resists GPU attacks better. I documented this in the threat model:

"PBKDF2 is less resistant to GPU brute force than argon2. We chose PBKDF2 because argon2 requires golang.org/x/crypto, which is not part of Go's standard library."

Judges want honesty about tradeoffs, not false claims of invincibility.

Cross-platform password input without echo

golang.org/x/term is the clean way to read passwords without showing characters on screen. It's not stdlib. I used syscall directly, which works but requires different code paths for Unix and Windows. Annoying, but functional.

PBKDF2 itself

Go has crypto/hmac and crypto/sha256. It does NOT have a PBKDF2 function. I implemented it by composing HMAC in a loop per RFC 2898.

The implementation is maybe 40 lines. But those 40 lines are the foundation of the entire vault, if the key derivation is wrong, every encryption is wrong. I validated against RFC 6070 test vectors before writing anything else. Those test vectors were my first commit's first test.

What I didn't expect

Go's stdlib is massive for security work. crypto/aes, crypto/cipher, crypto/hmac, crypto/sha256, crypto/rand, crypto/subtle, the entire AES-GCM + PBKDF2 + TOTP stack is in the box. I expected to hit walls. I didn't.
TOTP is deceptively simple. The RFC looks intimidating. The implementation is HMAC + a counter + truncation. The perceived complexity around 2FA evaporates when you read the spec.
Git's internal format is elegantly minimal. Zlib-compressed objects with a text header. No magic. Parse commits, follow trees, read blobs. A git history scanner doesn't need a git library, it needs compress/zlib and 200 lines of code.
html/template is more sophisticated than most third-party alternatives. It doesn't just escape HTML, it escapes based on context (HTML body, attribute, JavaScript, CSS, URL). Most template engines people install as dependencies don't do context-aware escaping this well.
The constraint clarifies more than it limits. Every time I reached for a package, the stdlib already had the primitive. The missing piece was never the tool, it was knowing how to compose what was already there.

📊 ZeroVault by the Numbers

┌──────────────────────────────────────────────────────┐
│                                                      │
│   ⏱  Build time ..................... ~12 hours     │
│                                                      │
│   📁 Go source files ................ 82            │
│                                                      │
│   ✅ Tests ........................... 115 (100%)   │
│                                                      │
│   📝 STDLIB.md entries .............. 22            │
│                                                      │
│   📦 Dependencies ................... 0             │
│                                                      │
│   🔒 Attack suite tests ............ 13             │
│                                                      │
│   🛡  Vulnerabilities found ......... 0              │ 
│                                                      │
│   🔄 Reproducible build ............ ✓ verified     │
│                                                      │
│   ⚡ AES-GCM throughput ............ ~1.0–1.6 GB/s   │
│                                                      │
│   🔑 PBKDF2 per attempt ............ ~300ms          │
│                                                      │
│   👤 Team size ...................... 1              │
│                                                      │
└──────────────────────────────────────────────────────┘

What I'd change for production

Being honest:

Argon2 instead of PBKDF2 for memory-hard key derivation
TLS for the web dashboard (currently localhost HTTP only)
Secure memory wiping with mlock/munlock
OS keychain integration instead of clipboard
Hardware security key support (FIDO2/WebAuthn)
Audit log with cryptographic chaining for tamper detection

Every one of these requires dependencies outside Go's stdlib. That's the tradeoff, and articulating it honestly is what the hackathon is about.

The point

The zero-dependency constraint isn't about proving packages are bad. I'd use gorilla/csrf and truffleHog in production without hesitation.

The constraint is about understanding what sits underneath. When you install a TOTP library, do you know it's just HMAC-SHA1 with a time counter? When you use AES-GCM, do you know why GCM and not CBC? When you install a git scanning tool, do you know it's reading zlib-compressed objects from .git/objects/?

After this hackathon, I do. And that understanding doesn't go away when I go back to installing packages on Monday.

One binary. One person. Zero dependencies.

🔗 GitHub: github.com/Aaditya2010-14/zerovault

🎥 Demo video: YouTube Demo Video

Try it yourself:

git clone https://github.com/Aaditya2010-14/zerovault.git
cd zerovault
go build -o zerovault ./cmd/zerovault
./zerovault demo    # password: demo2026

Built for Zero Dependency Hackathon 2026 — Track E: Security & Crypto Utilities

DEV Community: Aaditya2010-14