DEV Community: Shreya Dutta

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.