DEV Community: Shreya Dutta

I Built a Local AI 'Bad Cop' Because I Suck at Saying No to Freelance Scope Creep

Shreya Dutta — Mon, 19 Oct 2026 06:19:21 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 2: Side Hustle

What I Built

Let me tell you about the most expensive sentence in the freelance world: "Hey, quick question—this should only take 5 minutes, right?"

Two months ago, I took on a fixed-price freelance project to build a clean, static 3-page portfolio site for $1,200. Easy money, right? Well, halfway through week two, the client casually dropped a message asking if we could "quickly hook up a member login portal and a Stripe checkout before Friday so users can buy exclusive PDFs." Because I suffer from severe people-pleasing syndrome and hate awkward confrontations over money, I swallowed my pride, said "Sure, I'll squeeze it in," and spent my entire weekend fighting auth webhooks and database schemas for zero extra dollars. (╯°□°）╯︵ ┻━┻

When I finally did the math on Monday morning, I realized my effective hourly rate had tanked to pennies. And the worst part? It wasn't a coding problem—it was a boundary problem. Freelancers lose thousands of dollars every year not because they can't build, but because tracking contract drift and writing firm, polite pushback emails feels exhausting, awkward, and confrontational.

That is why I built ScopeGuard.

ScopeGuard is a local, zero-egress AI CLI tool that acts as an objective, non-emotional "bad cop" and Technical Project Manager for freelance developers, designers, and boutique agencies. You feed it two local files:

Your baseline Statement of Work (sow.txt).
The raw, chaotic email, Slack message, or WhatsApp text from your client (client_message.txt).

ScopeGuard cross-references the two locally, isolates every single feature request that falls outside your agreed baseline, calculates the hidden engineering complexity, and automatically drafts a warm, diplomatic, yet rock-solid Change Order email complete with itemized hour estimates, milestone impact, and pricing.

How the Side Hustle Works (Who Pays & Why?)

If you ask a solo freelancer to pay $49/month for a bloated enterprise project management SaaS, they will close the tab immediately. But if you offer a one-time $29 indie CLI license (or a $9/month micro-subscription) for a local tool that saves them $500 to $1,500 on the very first unbilled feature it catches? It pays for itself in thirty seconds. ¯\(ツ)/¯

Target Customers:

Solo Freelance Developers & Designers: Who want to stay in their terminal and write code instead of playing contract lawyer every Tuesday.
Student & Early-Career Freelancers: Who frequently get taken advantage of on fixed-price gigs because they are terrified of sounding "difficult" or losing a client.
Boutique 2–5 Person Dev Agencies: Who need standardized, polite Change Order responses across their client communication channels without exposing confidential client contracts to third-party cloud tools.

Demo

Here is ScopeGuard running locally in my terminal, catching a classic "quick Stripe + login portal" scope creep attempt and generating a ready-to-send Change Order response:

Sample Input vs. Output

1. Baseline Contract (sow.txt):

Project: Modern 3-Page Portfolio Website ($1,200 Fixed Fee)

Agreed Scope: Home page, About Me page, Static contact form via Formspree, responsive layout hosted on GitHub Pages.

Explicitly Excluded: Custom database backends, user authentication, payment processing, dynamic CMS integrations.

2. Incoming Client Request (client_message.txt):

"Hey, looking great so far! Quick thought before we launch: can we also add a member login portal so returning clients can download exclusive PDFs? Also, we'll need Stripe integration to charge $20 for access. Should be super quick to hook up right? Let's get that live by Friday!"

3. ScopeGuard Local Audit & Generated Response:

Scope Drift Analysis

In-Scope Confirmed: 3-page static layout (Home, About, Contact via Formspree), responsive design, static GitHub Pages deployment.

Out-of-Scope Drift Flagged (Financial Risk: HIGH):

Member Login Portal & Authentication: Violates the explicit Excluded clause ("user authentication, custom database backends"). Requires session management, user DB provisioning, and password reset flows.

Protected Digital Asset Delivery (PDFs): Requires authenticated route guarding and secure storage permissions rather than static hosting.

Stripe Payment Gateway Integration: Violates the Excluded clause ("payment processing"). Requires checkout session creation, webhook listeners, and payment state reconciliation.

Client Change Order Email

Subject: Re: Exciting additions! + Scope & Timeline Update for Member Portal & Stripe

Hi [Client Name],

Love where your head is at with monetizing the exclusive PDFs—adding a member portal and Stripe checkout is a fantastic way to turn the portfolio into a recurring revenue stream!

Because our original Statement of Work ($1,200 fixed fee) was scoped strictly for a static 3-page architecture without database backends, user authentication, or payment processing, transitioning the site into a full-stack application with secure login and Stripe webhooks falls outside our baseline agreement.

To build this securely and make sure your customers have a seamless checkout experience, I've put together a Change Order breakdown at my standard rate ($75/hr):

User Authentication & Member Portal Setup: 8 hours ($600)

Stripe Checkout & Webhook Integration: 6 hours ($450)

Secure PDF Delivery & End-to-End Testing: 4 hours ($300)

Total Change Order Addition: +18 Hours ($1,350 USD) | Timeline Impact: +5 Business Days

We have two great options to keep momentum going:

Phase 1 Launch (Recommended): We launch the static 3-page site this Friday as originally planned so you can go live on schedule, and tackle the Member Portal + Stripe as a separate Phase 2 milestone next week.

All-in Launch: I send over the formal Change Order for the additional $1,350 today, and we push our target launch date to next Friday to accommodate the backend engineering.

Let me know which path works best for you!

Code

arceuzvx / ScopeGuard

(If the GitHub embed takes a moment to load, you can explore the full repository here: https://github.com/arceuzvx/ScopeGuard)

Complete Implementation (`scopeguard.py`)

import sys
import time
from pathlib import Path
import ollama
import sentry_sdk
from rich.console import Console
from rich.panel import Panel
from rich.markdown import Markdown

# Initialize Sentry for agent execution & latency tracing
sentry_sdk.init(dsn="", traces_sample_rate=1.0)

console = Console()
RED = "bold red"
DARK_RED = "#8b0000"
MUTED = "#555555"

# Supports lightweight local models like gemma:2b or deep reasoning models like qwen3:14b
MODEL_NAME = "qwen3:14b"

def print_banner():
    banner = """
  ███████╗ ██████╗ ██████╗ ██████╗ ███████╗ ██████╗ ██╗   ██╗ █████╗ ██████╗ ██████╗ 
  ██╔════╝██╔════╝██╔═══██╗██╔══██╗██╔════╝██╔════╝ ██║   ██║██╔══██╗██╔══██╗██╔══██╗
  ███████╗██║     ██║   ██║██████╔╝█████╗  ██║  ███╗██║   ██║███████║██████╔╝██║  ██║
  ╚════██║██║     ██║   ██║██╔═══╝ ██╔══╝  ██║   ██║██║   ██║██╔══██║██╔══██╗██║  ██║
  ███████║╚██████╗╚██████╔╝██║     ███████╗╚██████╔╝╚██████╔╝██║  ██║██║  ██║██████╔╝
  ╚══════╝ ╚═════╝ ╚═════╝ ╚═╝     ╚══════╝ ╚═════╝  ╚═════╝ ╚═╝  ╚═╝╚═╝  ╚═╝╚═════╝ 
                 [ LOCAL SCOPE-CREEP & CONTRACT DRIFT DEFENDER ]
    """
    console.print(f"[{DARK_RED}]{banner}[/{DARK_RED}]")

def load_file(filename: str) -> str:
    path = Path(filename)
    if not path.exists():
        console.print(f"[{RED}][!] Error:[/{RED}] Missing file '{filename}'.")
        sys.exit(1)
    return path.read_text(encoding="utf-8")

def analyze_scope(sow_text: str, client_text: str):
    prompt = f"""You are a senior freelance contract negotiator and technical project manager.

ORIGINAL STATEMENT OF WORK (SoW):
{sow_text}

NEW CLIENT REQUEST:
{client_text}

TASKS:
1. Identify all items in the client's request that are OUT OF SCOPE relative to the original Statement of Work.
2. Draft a firm, polite, and professional email to the client:
   - Acknowledge their ideas enthusiastically.
   - Clarify that these additions fall outside the agreed baseline SoW.
   - Include a structured Change Order proposal with estimated hours, hourly rate ($75/hr), and milestone impact.

FORMAT YOUR RESPONSE AS:
# Scope Drift Analysis
- **In-Scope Confirmed:** <items>
- **Out-of-Scope Drift:** <items flagged with financial risk>

# Client Change Order Email
<Draft email here text>
"""
    console.print(f"[{MUTED}][*] Running local inference on {MODEL_NAME} via Ollama (Sentry tracing active)...[/{MUTED}]")
    start_time = time.time()

    with sentry_sdk.start_transaction(op="ai_inference", name="Scope Drift Check"):
        response = ollama.chat(
            model=MODEL_NAME,
            messages=[{'role': 'user', 'content': prompt}]
        )

    latency = time.time() - start_time
    return response['message']['content'], latency

def main():
    print_banner()
    sow_content = load_file("sow.txt")
    client_content = load_file("client_message.txt")

    console.print(f"[{DARK_RED}]─── Loaded Local Files ──────────────────────────────────────[/{DARK_RED}]")
    console.print(f"[{MUTED}][+] sow.txt ({len(sow_content)} chars) | [+] client_message.txt ({len(client_content)} chars)[/{MUTED}]\n")

    result, latency = analyze_scope(sow_content, client_content)

    console.print(Panel(Markdown(result), border_style=DARK_RED, title="[bold red]ScopeGuard Audit Report[/bold red]"))
    console.print(f"\n[{MUTED}][*] Trace Complete | Latency: {latency:.2f}s | Zero Cloud Data Egress.[/{MUTED}]")

if __name__ == "__main__":
    main()

How I Built It

Honestly, building this today was a pure hackathon rollercoaster. I originally planned to scaffold the entire application using cloud-based coding models inside OpenCode, and within ten minutes I slammed headfirst into an API Rate Limit Exceeded wall. Panic mode immediately set in. I decided to pivot entirely to my local machine, fired up ollama serve in PowerShell, and immediately got slapped with a nasty Windows error: listen tcp 127.0.0.1:11434: bind: Only one usage of each socket address is normally permitted. (－‸ლ)

After losing ten precious minutes wondering what rogue process hijacked my port, I realized the Ollama background tray daemon was already silently running and listening on 11434. Once I stopped fighting my own operating system, everything clicked into place.

Here is how the technical pipeline is architected:

Local Open-Weight Inference (Ollama + Qwen3:14b / Gemma:2b): The core reasoning engine runs 100% locally via the ollama Python SDK. The script is designed to be model-agnostic—working seamlessly with qwen3:14b for deep contract nuance or Google's lightweight gemma:2b for rapid inference on lower-spec laptops.
Adversarial & Role-Based Prompt Engineering: Out of the box, LLMs are trained to be helpful and agreeable. If you casually ask an AI to "reply to this client email," it will happily write a response agreeing to do 20 hours of free database work! I engineered the system prompt to force the model into the persona of a Senior Technical Project Manager & Contract Negotiator. It explicitly hunts for Exclusion Clauses in the SoW, translates vague client requests ("quick login") into concrete backend sub-tasks (database provisioning, session middleware, webhook security), and automatically introduces a "Phase 1 vs. Phase 2" psychological anchor so the client feels guided rather than rejected.
Minimalist Terminal UI (Rich): I wanted ScopeGuard to feel like a sharp cybersecurity CLI utility rather than a bloated web dashboard. Using Python's rich library, I styled the interface in a pitch-black and blood-red (#8b0000) aesthetic that parses and renders the LLM's Markdown output inside clean console panels.
Execution Telemetry (Sentry SDK): Running local models requires keeping a close eye on hardware responsiveness. I wrapped the ollama.chat() call inside a sentry_sdk.start_transaction() span to benchmark inference latency from prompt dispatch to completion.

Why Does Open Innovation Matter?

When I first pitched this concept to a friend, their immediate reaction was: "Wait, why wouldn't a freelancer just copy-paste their contract and client email into ChatGPT?"

Two words: Non-Disclosure Agreements (NDAs).

Almost every legitimate freelance contract, consulting agreement, or agency Master Services Agreement (MSA) contains a strict confidentiality clause. When a client sends over a Statement of Work and follow-up feature requests, those documents contain sensitive IP:

Unreleased product roadmaps and proprietary business features.
Internal software architectures and security boundaries.
Private pricing tiers, hourly rates, and client identities.

If a freelancer copy-pastes their client's confidential SoW and private emails into a closed, third-party cloud API, they are actively violating their NDA and exposing client data to external servers.

Open-source, local AI isn't just a "nice-to-have" here—it is the only reason ScopeGuard can legally and financially work:

100% Data Sovereignty & NDA Compliance: Because ScopeGuard executes open-weight models via Ollama strictly on 127.0.0.1, zero bytes of client contract data ever leave the freelancer's laptop. You can literally turn off your Wi-Fi on an airplane and audit five sensitive client contracts with zero compliance risk.
Zero Subscription Bleed ($0.00 Unit Economics): When building a micro-tool for indie freelancers, paying recurring cloud API token fees destroys your margins. By running open weights locally on the user's existing hardware, the marginal cost per contract audit is $0.00. ᕙ(⇀‸↼‶)ᕗ
No Vendor Lock-In or Sudden Deprecations: Closed API providers routinely deprecate model checkpoints or alter system behavior overnight, which breaks carefully tuned negotiation formatting. Open weights let developers lock in exact local model versions (gemma:2b or qwen3:14b) and swap them with a single variable change.

My First User

Right after I got the terminal output working, I hopped on Discord and demoed ScopeGuard to a close developer friend from our university hackathon community who builds freelance React and Next.js sites on the side to help pay for college.

We tested it on an actual WhatsApp message he received earlier this month from a local business client. The client had paid for a static landing page, and then texted asking for "a quick admin dashboard where I can log in and crop/upload new gallery photos myself." We dropped his original deliverables list into sow.txt and the client's text into client_message.txt.

ScopeGuard immediately flagged the request as high-risk scope creep—breaking down why an admin dashboard requires cloud storage buckets, image processing pipelines, and authentication—and drafted a polite Change Order quoting an extra $450 (6 hours) with a Phase 1 / Phase 2 launch option.

His literal reaction on the Discord call was: "Bro, push this to GitHub right now. Last month I built a whole Firebase admin panel for free because I was scared the client would leave a bad review if I asked for more money. The Phase 1 vs Phase 2 line in this email is actually genius."

He hasn't handed me $29 in cash yet (though he did promise to treat me to biryani next week ◕‿◕), and he already gave me my first two user feature requests:

Direct PDF/DOCX Ingestion: So he can drop a signed PDF contract directly into the folder without copy-pasting into .txt first.
A --tone CLI Flag: Allowing freelancers to toggle between --tone gentle (for long-term repeat clients) and --tone strict (for serial boundary-pushers).

Prize Categories

Best Use of Gemma: Designed and validated the local Ollama prompt pipeline to support fast, lightweight local inference on Google's open-weight gemma:2b model alongside qwen3:14b.
Best Use of Sentry Agent Tracing: Instrumented the local LLM inference execution block with sentry-sdk transaction spans to monitor local hardware latency.

Build to Break: Your Guide to Cybersecurity at Hacktoberfest HackDay x OWASP JIS Univerity

Shreya Dutta — Sun, 27 Sep 2026 12:34:08 +0000

OWASP × Hacktoberfest Cybersecurity Track

Build. Break. Secure.

Welcome to Hacktoberfest Hack Day Kolkata x OWASP JIS University 💖

Build a project that solves a real cybersecurity problem.

Your project can focus on application security, cloud security, AI security, authentication, supply-chain security, detection and response, DevSecOps, or another security challenge.

You don't need to build a complete enterprise security platform. Pick one meaningful problem, build a focused solution, and demonstrate that it works.

What Can You Build?

Here are some areas to explore:

Web & API Security

API authorization tester
IDOR/BOLA detector
Web vulnerability scanner
Secure API gateway
Authentication security tool

Cloud Security

IAM privilege-escalation analyzer
Cloud misconfiguration scanner
Cloud attack-path visualizer
Exposed credential detector
Cloud security monitoring tool

AI Security

Prompt-injection detector
LLM security testing tool
AI data-leakage detector
Secure AI-agent permission layer
AI-generated code security analyzer

DevSecOps & Supply Chain

CI/CD security gate
Secret detection and remediation tool
Dependency/SBOM risk analyzer
Container security scanner
Infrastructure-as-Code security analyzer

Detection & Response

Security-log correlation tool
Attack-chain reconstruction
Threat-intelligence enrichment tool
Security alert triage system
Automated incident-response assistant

These are starting points, not restrictions. If you have a different cybersecurity idea, build it.

How to Approach Your Project

A simple way to structure a cybersecurity project is:

┌──────────────┐
│   Problem    │
└──────┬───────┘
       ↓
┌──────────────┐
│    Attack    │
└──────┬───────┘
       ↓
┌──────────────┐
│   Security   │
│    Control   │
└──────┬───────┘
       ↓
┌──────────────┐
│ Demonstrate  │
│   & Test     │
└──────────────┘

1. Define the Problem

Ask:

What are you trying to protect, and what are you protecting it from?

For example:

Problem: Exposed API credentials can be used to access sensitive resources.

Attacker: Someone who obtains a leaked credential.

Impact: Unauthorized access to data or services.

2. Understand the Attack

Before building the solution, understand how the attack actually happens.

Think about:

Attacker → Attack Vector → Vulnerability/Weakness → Impact

For example:

Attacker
   │
   ▼
Stolen API Key
   │
   ▼
Unauthorized API Access
   │
   ▼
Sensitive Data Exposure

Your project should intervene somewhere in this attack path.

3. Build the Security Control

Your project should do something about the security problem.

For example:

Source Code
    │
    ▼
Secret Scanner
    │
    ▼
Credential Detected
    │
    ▼
Alert / Block Commit

Or:

IAM Policy
    │
    ▼
Permission Analysis
    │
    ▼
Privilege Escalation Path
    │
    ▼
Finding + Remediation

Or:

Security Logs
    │
    ▼
Detection Engine
    │
    ▼
Suspicious Activity
    │
    ▼
Alert / Investigation

The goal isn't to have the most features. A focused security control that works is more valuable than a large collection of unfinished features.

Using Open-Source & Open-Weight AI

Hacktoberfest is about building with open source, including open-source and open-weight AI models.

If your project uses AI, we encourage you to use an appropriate open-source or open-weight model rather than relying entirely on a proprietary API.

You can use Gemma, but Gemma is not the only option.

Depending on your project, you could explore models such as:

Gemma
Llama
Mistral
Qwen
Phi
Other appropriately licensed open-source/open-weight models

Choose the model based on what your project actually needs.

Make the AI contribution clear

Don't just write:

"We used an open-source AI model."

Explain what the model does in your project and why you chose it.

For example:

Security Detection
       │
       ▼
Open-Source / Open-Weight Model
       │
       ▼
Explanation / Correlation
       │
       ▼
Remediation Recommendation

Good uses for AI include:

Explaining security findings
Correlating security events
Summarizing incidents
Classifying security data
Extracting threat intelligence
Suggesting remediation
Providing a natural-language interface to security tooling

Document how you used the model

Consider adding a skills.md file or similar documentation to your repository.

Use it to explain things such as:

Which model you used
Why you chose it
Where it is used in your architecture
What tasks it performs
How you run it
Any important limitations
How developers can reproduce or modify the AI component

The goal is to make your use of open-source/open-weight AI visible, understandable, and reproducible.

Be Careful With AI-Generated Actions

Treat model output as untrusted input, especially if it generates:

SQL
Shell commands
IAM policies
Kubernetes configurations
Code
API requests

Prefer:

AI Output
    │
    ▼
Validation
    │
    ▼
Controlled Action

rather than:

AI Output
    │
    ▼
Production

Your AI model should not automatically become the root of trust for a security-critical operation.

Test Your Project Like an Attacker

Don't only demonstrate the happy path.

Try to break your own system.

At minimum, test:

Normal input
Malicious input
Invalid input
Unexpected input
Edge cases

For example:

Prompt-Injection Defense

Normal Prompt
     ↓
   Works

Malicious Prompt
     ↓
Injection Detected
     ↓
   Blocked

IAM Security Tool

Vulnerable Policy
       ↓
Privilege Escalation
       ↓
     Detected
       ↓
Remediation Suggested

Secret Detection

Leaked Credential
       ↓
    Detected
       ↓
Commit Blocked
       ↓
Developer Alerted

Prove That It Works

A cybersecurity project should be demonstrated with an actual security scenario.

A simple structure is:

Attack → Detection/Prevention → Result

Don't just show a dashboard and say:

"Our system detects attacks."

Show the attack.

Show what your system detects or prevents.

Show the result.

Keep Your Claims Realistic

Avoid making claims that you cannot demonstrate.

Instead of:

"Our system completely prevents phishing."

Explain what your system actually does:

"Our system detects suspicious websites using URL, DOM and visual features."

Instead of:

"Our AI guarantees secure code."

Say:

"Our AI identifies potential security issues and suggests remediation."

If you report metrics such as accuracy, explain how you measured them.

For example:

What dataset did you use?
How many test cases?
How many attacks were detected?
How many false positives?
How many false negatives?

Useful Resources

OWASP

OWASP Top 10:2025
A starting point for understanding common application-security risks and finding project ideas.

OWASP Top 10 for LLM Applications
Useful for projects involving LLMs, GenAI, AI agents, or open-source/open-weight models.

OWASP Cheat Sheet Series
Practical implementation guidance for common security topics.

OWASP API Security Top 10
Useful if your project involves APIs, authentication, authorization, or access control.

OWASP Web Security Testing Guide
Use this to test your web application before submission.

Open-Source AI

If you're building with AI, explore open-source and open-weight models and choose one that fits your project's requirements.

For the Google Gemma track, you can start with:

Google Gemma

You are not required to use Gemma for every AI-based cybersecurity project. Other appropriately licensed open-source/open-weight models are also valid for the broader Open-Source AI theme.

Need More Project Ideas?

OWASP GSoC Project Ideas
Explore real OWASP open-source projects and technical problem areas for additional inspiration.

OWASP Project Directory
Browse existing OWASP projects across application security, AI security, cloud security, tooling, and more.

These are provided for inspiration and further exploration. You do not need to contribute to an existing OWASP project for the Hackday.

Final Checklist

Before submitting, ask yourself:

[ ] What security problem am I solving?
[ ] Who is the attacker?
[ ] How does the attack work?
[ ] What does my project detect, prevent, or mitigate?
[ ] Can I demonstrate the attack?
[ ] Can I demonstrate my security control working?
[ ] Have I tested malicious and unexpected inputs?
[ ] Are my security/AI claims supported by evidence?
[ ] If I use AI, is it actually contributing something meaningful?
[ ] Have I clearly documented which open-source/open-weight model I used and how?
[ ] Can another person understand and reproduce my project?

The Basic Formula

Problem → Attack → Security Control → Test → Result

You don't need to build the next enterprise security platform.

Pick one real security problem. Understand it. Build a focused solution. Try to break it. Then demonstrate that your solution works.

All the best. :) 🎉

How Strong Is Dropbox Password Security? Real Password Crack Time Analysis Using Modern GPU Models

Shreya Dutta — Sun, 08 Feb 2026 06:33:31 +0000

Hey everyone 👋🏻 I’m Shreya, a Computer Science student with cyber security as a specialization, exploring the various areas in Information Security. Today’s blog covers password policy analysis with Dropbox as a case study.

Password Policy Analysis — Dropbox

Password policy (Observed + Documented behavior):

At least 8 characters
Encourages letters, numbers, symbols (UI driven strength feedback)
Pattern / common password detection (not just character rules)

Though it doesn’t meet the 12 character requirement like many newer orgs these days, 8 characters is pretty much the minimum baseline still accepted across many platforms. Modern security guidance is slowly pushing toward 12–16+ characters as safer defaults.

Industry reality:

8 = legacy baseline
10–12 = modern baseline
14–16 = strong modern

Also to note, there’s no strict Upper/Lower case enforcement rule publicly documented, which can look like a drawback from a traditional complexity-rule viewpoint, but modern systems often prefer entropy + pattern detection instead of forcing predictable complexity substitutions.

Dropbox actually uses password strength detection that compares passwords against common words, names, patterns and numbers to prevent easy-to-guess passwords.

For more info: https://help.dropbox.com/security/password-control

Dropbox also recommends longer passwords, unique passwords per service, and enabling 2FA or passkeys for stronger protection.
Here: https://help.dropbox.com/security/secure-password

Passwords to Test

password_123
bluey#1996
bg@1996_dropbox

Detailed Explanation For Why Each Password Will Eventually Be Cracked

1️⃣ password_123

Very common password variant of this being “password123” has been in pretty much every password leak databases for years now, so this variant will also be cracked easily.

Attack reality:

This would likely be cracked instantly using credential stuffing or breach database matching, not brute force.

2️⃣ bluey#1996

Identical to email/first name plus 1996 could highly mean their birth year.

A little digging about the person’s identity and boom you have it all with all possible variants with name/birthdate etc.

Attack reality:

This is classic OSINT-derivable password construction.

3️⃣ bg@1996_dropbox

Abbreviation of name + year + website they’re signing up for along with 2 special characters.

Slightly better than last 2 but still very predictable as it’s a combo of name/DOB/website. Still not secure enough.

Attack reality:

Attackers specifically test service-name + year + initials combos.

Crack Time Testing

Went a step ahead and checked how long it’ll take hackers with modern tools to crack the above three.

Results:

First 2 → under 1 sec
Third → ~8 hrs

Important Context

These tools estimate brute-force cracking assuming:

No prior knowledge
No breach database
No OSINT

Real attackers usually try:

Leaks
Pattern mutations
OSINT guessing
Then brute force

You can try it on:

https://www.mypasswordchecker.com/

4th Password — Password Manager Style

I’d like to take a 4th password for the analysis, something that Google password manager would suggest:

XFu2&3fM^Tm&&2#

Looks like sci-fi but let’s see:

It does say very strong but modern GPUs can theoretically crack it in <12 days (pure brute force estimate assuming high compute resources).

Real-World Note

Without:

Breach exposure
Password reuse
Offline hash cracking

Attackers are unlikely to brute force something like this unless extremely high value target scenario.

Conclusion

Looks like we need to step up the password game.

Real Modern Direction

Longer passwords / passphrases
Unique per service
Password manager usage
MFA / Passkeys

Extra Real-World Security Context

Modern password strength systems don’t just check symbols. They check:

Common password lists
Human language patterns
Keyboard patterns
Known leaks

Research shows machine learning models can now learn real human password behavior from leak datasets and improve password guessing success significantly.

Also, password strength meters themselves can leak pattern info or be gamed if poorly designed.

Cool Research Papers to Explore

Human Password Modeling Research

https://arxiv.org/abs/2407.14145

Password Strength Meter Risks Research

https://arxiv.org/abs/2505.08292

Password Entropy Theory

https://arxiv.org/abs/2404.16853

NOTE

Most accounts are NOT hacked via brute force.

Most are compromised via:

Password reuse
Phishing
Malware / infostealers
Credential stuffing

Passwords are slowly becoming just one layer of authentication.

Hope you liked the write-up 🙂

Follow up in X / Twitter.

DEV Community: Shreya Dutta

I Built a Local AI 'Bad Cop' Because I Suck at Saying No to Freelance Scope Creep

What I Built

How the Side Hustle Works (Who Pays & Why?)

Demo

Sample Input vs. Output

Scope Drift Analysis

Client Change Order Email

Code

arceuzvx / ScopeGuard

Complete Implementation (scopeguard.py)

How I Built It

Why Does Open Innovation Matter?

My First User

Prize Categories

Build to Break: Your Guide to Cybersecurity at Hacktoberfest HackDay x OWASP JIS Univerity

OWASP × Hacktoberfest Cybersecurity Track

Build. Break. Secure.

What Can You Build?

Web & API Security

Cloud Security

AI Security

DevSecOps & Supply Chain

Detection & Response

How to Approach Your Project

1. Define the Problem

2. Understand the Attack

3. Build the Security Control

Using Open-Source & Open-Weight AI

Make the AI contribution clear

Document how you used the model

Be Careful With AI-Generated Actions

Test Your Project Like an Attacker

Prompt-Injection Defense

IAM Security Tool

Secret Detection

Prove That It Works

Keep Your Claims Realistic

Useful Resources

OWASP

Open-Source AI

Need More Project Ideas?

Final Checklist

The Basic Formula

How Strong Is Dropbox Password Security? Real Password Crack Time Analysis Using Modern GPU Models

Password Policy Analysis — Dropbox

Detailed Explanation For Why Each Password Will Eventually Be Cracked

1️⃣ password_123

2️⃣ bluey#1996

3️⃣ bg@1996_dropbox

Crack Time Testing

Important Context

4th Password — Password Manager Style

Real-World Note

Conclusion

Real Modern Direction

Extra Real-World Security Context

Cool Research Papers to Explore

NOTE

Complete Implementation (`scopeguard.py`)