Hey there! I'm a first-year student, and a few weeks ago, I realized something: I'd been learning about authentication, hashing, and cybersecurity for months, but I couldn't explain how any of it actually worked. So I decided to stop watching tutorials and start building something real.

That's when VAULT CLI was born — and honestly, it changed how I think about security engineering.

The Problem I Started With

I was sitting in class, half-listening to a lecture about bcrypt vs SHA256, when it hit me: I don't understand why we even care which one we use. I knew the buzzwords — "slow hashing," "brute-force resistance," "cost factor" — but it all felt like magic.

Then I thought: What if I just… built an authentication system myself?

Not a polished production system (I'm definitely not qualified for that yet). But something simple enough to understand, yet complex enough to matter. Something where I could see why security matters, not just memorize that it does.

What I Built

VAULT CLI is a terminal-based authentication system written in Python. It includes:

  • User registration and login with real security mechanisms
  • bcrypt password hashing (not storing passwords as plain text like a monster)
  • Account lockout after failed login attempts
  • Security logging that tracks what happened
  • An attack simulator that shows how easy it is to crack weak passwords

Basically, it's the kind of system you'd find protecting millions of accounts — except mine has maybe 10 lines of documentation and lives in a GitHub repo.

The "Aha!" Moments

Moment 1: Why Speed Kills Security

I built a simple script that compared hashing speeds:

SHA256: 100,000 hashes per second
bcrypt: 50 hashes per second

That doesn't sound like much, right? But imagine an attacker trying common passwords:

  • With SHA256: They can try 100,000 passwords per second. A 6-character password? Cracked in milliseconds.
  • With bcrypt: They can try 50 passwords per second. That same 6-character password takes hours.

Suddenly, "use bcrypt" wasn't a random rule anymore — it was physics. Security is expensive by design.

Moment 2: Logging Actually Matters

I was building the audit logger, thinking it was unnecessary overhead. But then I realized: How would I even know if someone was attacking my system?

I added logging for:

  • Successful logins
  • Failed attempts
  • Account lockouts

Now when I look at the logs, I can see patterns. Three failed attempts in 10 seconds? That's a brute-force attack. Fifty failures from different IPs? Someone's running a dictionary attack.

Security isn't just about preventing attacks — it's about seeing them happen.

Moment 3: Lockout Systems Have Trade-offs

Here's something I didn't expect: After 3 failed login attempts, the account locks for 15 minutes.

This is secure — it stops brute-force attacks dead.

But it also means someone could lock your account just by guessing wrong 3 times. That's a Denial-of-Service vulnerability.

Real systems solve this with email notifications, 2FA, or smarter detection. I realized there's no such thing as "secure" — only "secure against this specific threat while accepting these other risks."

Moment 4: Understanding Attacker Mindset

I built a simple cracker that does dictionary attacks:

python

with open('common_passwords.txt') as f:
    for password in f:
        if bcrypt.checkpw(password, hashed):
            print("CRACKED!")

Now when I see a user register with "password123," I viscerally understand why that's terrible. Because I literally just wrote the code that cracks it.

Building attack tools changes how you think about defense.

The Stack (Keeping It Simple)

  • Python 3 — I'm not trying to be fancy
  • SQLite — Local database, no setup needed
  • bcrypt — Industry standard for password hashing
  • logging module — Built-in Python, no extra deps
  • getpass — Masks password input in terminal

What I Learned Beyond Code

  1. Security is unglamorous: No flashy animations, just boring text logs that prevent disasters.
  2. Real systems are complicated: My little project made me appreciate why cybersecurity teams exist at real companies.
  3. Understanding > Memorizing: I'll never forget why bcrypt matters because I built the speed comparison myself.
  4. Logging is underrated: Everyone talks about algorithms, but logs are what actually let you see attacks happening.
  5. Trade-offs are everywhere: There's no perfect solution, only better solutions for your specific threat model.

So… Is It Useful?

Not really. There are a million better authentication libraries.

But is it valuable? Absolutely. Because I don't just know how authentication works anymore — I built it. And that's a completely different thing.

Try It Out

If you want to understand authentication systems instead of just memorizing them, you can check out the code: https://github.com/Dhanuskiruthick/VAULT-CLI

It's messy, it's underdocumented, and there are probably security holes. But it's real, and it taught me more than a semester of theory ever could.

What's Next?

I'm thinking about adding:

  • Multi-factor authentication (MFA)
  • Session tokens
  • Role-based access control
  • Maybe even a REST API version

But honestly? I'm just happy I finally understand why password security matters. And maybe that's the whole point.

TLDR: I built an authentication system to understand security instead of just reading about it. Turns out, building stuff is the best way to learn. Who knew?

If you're a student interested in security, don't watch another tutorial — build something. Even if it's a terrible version of something that already exists. Especially if it's terrible.

Have you built something to understand how it works? Drop a comment — I'd love to hear about it.

Note: This project is for educational purposes. Please don't use it in production. Please.