DEV Community: Bijan

The oracle problem

Bijan — Sun, 11 Oct 2026 12:06:23 +0000

Just faced the oracle problem in blockchain, and got different definitions. Which one do you think is true?

"If oracles allow corrupt data to be imported on-chain, auto-executing smart contracts can have disastrous affects" - from Ethereum stack exchange
"The Oracle Problem is the challenge of securely and reliably bringing external data onto a blockchain, where smart contracts cannot independently verify that data and must rely on some mechanism to establish its trustworthiness." - AI
"Blockchain doesn't understand real-world data, and you can't give the data to it from a centralized point cause the purpose of blockchain is decentralization. So we use oracles like Chainlink made out of multiple nodes, so they confirm the data validity and pass to the blockchain. Decentralized, valid, accurate and reliable." - What I learned

What do you think?

I Gave My SOC Experience to AI. It Gave Me Sigma Rules.

Bijan — Thu, 08 Oct 2026 17:00:00 +0000

After spending time in a SOC, you start noticing patterns.

Different alerts. Different machines. Different incidents.

But eventually, you realize that a lot of the attacks you're seeing aren't completely new.

The same techniques keep coming back.

An Office application spawning something it shouldn't.

PowerShell being used in suspicious ways.

Security controls being tampered with.

Software quietly abusing system resources.

You see these things, investigate them, stop them, and move on to the next alert.

I started wondering:

What if I took some of the attack scenarios and TTPs I've actually encountered and turned them into reusable detection rules?

That's how I started working on SigmaVault.

I provided AI with some of the attack scenarios and TTPs I'd encountered and stopped during my SOC work, then asked it to generate Sigma rules around those scenarios.

The goal wasn't to blindly generate a pile of rules and call it detection engineering.

I wanted to experiment with something more useful:

Can practical SOC experience be turned into structured, reusable detections?

For example, instead of keeping an attack pattern in my head as:

"I've seen this behavior before."

I can turn it into something closer to:

Attack behavior
      ↓
Relevant telemetry
      ↓
Detection logic
      ↓
Sigma rule
      ↓
SIEM / detection pipeline

There is one important disclaimer, though.

The rules aren't tested yet.

So I'm treating SigmaVault as a work in progress rather than claiming these are production-ready detections.

The next step is testing and tuning them against real telemetry, looking at false positives, and figuring out where the generated logic actually holds up.

And I'm not planning to stop with the initial scenarios.

I'd like to expand the project with more attack techniques and eventually add Linux-focused detections as well.

That's what makes this project interesting to me.

It's not really about getting AI to write YAML.

It's about taking things I've encountered in the SOC, turning them into detection hypotheses, and then testing whether those hypotheses can become useful detection logic.

Maybe some rules will be wrong.

Maybe some will be noisy.

Maybe some will actually turn out to be useful.

That's the part I want to find out.

SigmaVault:
https://github.com/bijan53c/SigmaVault

If you spot something that could be improved, or have a detection scenario worth adding, let me know.

Hope it helps someone else working on their own detection engineering journey.

You don't know how to work!

Bijan — Sun, 04 Oct 2026 09:34:19 +0000

I've been reading Slow Productivity by Cal Newport, and one idea in it made me stop and actually change something: working in a way that's aligned with how humans are wired to focus, instead of the always-on pace most jobs and corporations run on by default.

I stopped tracking my work by time I've put, reduced the tasks and parallel projects I've been doing together; instead I'm tracking what tasks of each project I'm working on, setting complexity meter to each, and writing the output of each.

It's a small shift, but it's made my work in bug bounty hunting and personal projects noticeably less frantic and, honestly, more consistent.

I don't think this is a one-person hack — I think most workplaces would benefit from applying even one or two of these principles deliberately, instead of optimizing purely for busyness.

Have you read it? If so, what's the one idea from it that actually changed how you work — not just how you think about work?

I Found an Access Control Bug in My First Solidity Contract

Bijan — Fri, 02 Oct 2026 17:00:00 +0000

I revisited my first Solidity contract and found a simple access control bug — and learned why Solidity's address(0) default behavior mattered to the fix.

I found an access control bug hiding in plain sight.

SimpleStorage lets users save data by ID. Here's the version I originally wrote:

function AddData(uint256 _ItemID, string memory _StringData) public {
    DataIdToData[_ItemID] = EntryData(_StringData, msg.sender);
}

At a glance, it looks harmless.

It isn't.

There was no check for who already owned _ItemID.

That meant anyone could call AddData() with an ID that belonged to someone else and overwrite their entry.

The caller would then become the new owner.

No error.
No revert.
No access control.

Just a successful transaction.

The fix

The fix was a simple ownership check:

require(
    DataIdToData[_ItemID].Owner == msg.sender ||
    DataIdToData[_ItemID].Owner == address(0),
    "this ID is assigned to someone else!"
);

Now a write is only allowed when:

The caller already owns the ID, or
The ID hasn't been claimed yet.

The second condition is where something I previously found confusing in Solidity suddenly became useful.

`address(0)` isn't just a default

An address field that hasn't been explicitly initialized returns Solidity's zero address:

address(0)

So an untouched entry can effectively act as:

Owner = address(0)
        ↓
Nobody owns this ID yet

And that gives the contract a simple way to distinguish an unclaimed ID from an owned one.

A few days ago, I wrote about how confusing Solidity's default storage values were when I was first learning.

Now I'm using that exact behavior to implement an ownership check.

That's probably the part I find most interesting about learning Solidity:

The thing that confused me as a beginner can eventually become part of the security model.

I'm still early in this.

But I'm starting to find the gaps in my own contracts before someone else has to point them out.

The Line of Code That Makes Every Encryption Unique — Even With the Same Password

Bijan — Mon, 28 Sep 2026 17:00:00 +0000

Same message. Same password. Same key. Two completely different ciphertexts. That's not a bug — it's a requirement, and it comes down to a single value that's easy to overlook: the nonce.

This is the final post in a series documenting what I'm learning building CryptoGraphy.

Why identical ciphertext for identical plaintext is a real problem

If the same plaintext always produced the same ciphertext under a given key, an attacker watching encrypted traffic could spot patterns without ever breaking the encryption itself. "This exact ciphertext shows up every time this user logs in." "This ciphertext matches the one sent yesterday, so the underlying message is probably identical." None of that requires cracking the key — it's leaking information through metadata and repetition, which is its own category of failure separate from confidentiality.

Where the nonce comes in

In crypto.py, a fresh nonce is generated for every single call to encrypt():

NONCE_SIZE = 12

def encrypt(plaintext: bytes, key: bytes) -> tuple[bytes, bytes]:
    nonce = os.urandom(NONCE_SIZE)
    aes = AESGCM(key)
    ciphertext = aes.encrypt(nonce, plaintext, None)
    return nonce, ciphertext

That 12-byte nonce gets mixed into the AES-GCM encryption process, and its presence is what guarantees the output is unique every time — even with the exact same key and the exact same message. It's returned alongside the ciphertext because it needs to be available again at decryption time:

def decrypt(ciphertext: bytes, key: bytes, nonce: bytes) -> bytes:
    aes = AESGCM(key)
    return aes.decrypt(nonce, ciphertext, None)

The nonce doesn't need to be secret — it needs to never repeat

This mirrors the salt from earlier in this series, and it trips people up the same way. The nonce isn't hidden — it's stored right alongside the ciphertext, in the clear. Its job was never secrecy. Its only job is uniqueness: it must never repeat under the same key. That's it. That's the entire requirement, and it's also the requirement that's dangerously easy to violate without realizing it.

What actually happens if you reuse one

This is the part that makes nonce handling load-bearing rather than a formality. Reuse a nonce with AES-GCM under the same key — even once — and you don't just weaken the encryption slightly. You can fully break the confidentiality of both messages encrypted with that repeated nonce, and depending on what an attacker can access, potentially recover the authentication key used for the integrity tag as well, undermining the tamper-detection property covered in the previous post too.

This isn't a theoretical edge case in an academic paper. Nonce reuse under AES-GCM is one of the most common real-world implementation bugs in systems that otherwise look like they got everything else right — it's happened in production systems, including ones built by teams who clearly understood the rest of the AEAD design. The failure mode is specifically nasty because everything looks fine until the exact moment a nonce collides, at which point the damage isn't "slightly weaker encryption" — it's a full break.

Why "generate it fresh, every call" is the whole mitigation

os.urandom(12) on every single call to encrypt() is the entire fix. A 12-byte (96-bit) random nonce, generated properly, makes accidental collision astronomically unlikely for any realistic volume of messages under a single key. The mitigation isn't complicated — it's just non-negotiable. Caching a nonce, deriving it predictably, or reusing one across calls "just this once" is exactly the kind of shortcut that looks harmless in a demo and catastrophic in production.

The takeaway across this whole series

Looking back across all five posts: a derived key instead of a raw password, a random salt, a deliberately slow and memory-hard KDF, an AEAD cipher instead of plain AES, and a fresh nonce on every call. None of these individually are exotic. Every one of them is a single function call or a small config value. And every single one of them is a place where skipping the "obvious" step quietly turns working code into broken security.

That's been the actual lesson of building this project: applied cryptography isn't hard because the concepts are exotic. It's hard because almost every step has a version that looks correct, runs without errors, and is still wrong in a way that only shows up under attack.

Full project (with all five concepts implemented) is at CryptoGraphy.

Have you seen a real nonce-reuse vulnerability in the wild? I'd genuinely like to hear the story.

I Gave AI Hands on a Virtual Machine — Here's What Changed

Bijan — Mon, 28 Sep 2026 14:00:00 +0000

I think AI is the closest thing to what Google search was when it first went public — it didn't replace anyone's job, it made a whole category of work faster, and "knowing how to use it well" became its own skill. Some people reach for the WordPress comparison instead, when talking about vibe coding and the worry it put into web developers a decade ago. Either analogy lands the same way for me: this is a new capability layer, not a replacement for the person using it.

I'm an ethical hacker — I've worked both defense (SOC) and offense (red team, pentesting, bug hunting), which means my day covers everything from planning and scripting to configuring machines and finding and exploiting vulnerabilities, ethically. AI's role in that day has changed a lot over the past while, and the change is worth being specific about, because "I use AI" doesn't actually say much on its own.

How I used to use it: five models, zero shared context

For a while I ran different providers for different jobs, because each one genuinely had different strengths. Gemini for fast, deep search. Claude for coding. ChatGPT for translation. Grok and DeepSeek sitting in reserve for whenever I ran out of tokens on the primary set.

It worked, but it had two real costs. First, models don't share context — handing code from Claude to another model to continue working on it could quietly break things, because the second model has no idea what assumptions the first one made. Second, every switch meant starting from zero: re-explaining the same context, constraints, and goals to a model that had no memory of the conversation you'd just had somewhere else.

If you're running into the same problem, the practical fix is less exciting than it sounds: pick the provider whose pro tier actually covers most of what you need, and stop routing around token limits by hopping providers mid-task.

How I use it now: an agent with hands, on a machine I can delete

The bigger shift wasn't switching tools — it was giving one of them the ability to act directly. I run Claude Code on a virtual machine, which means I'm not copying output back and forth or manually following step-by-step instructions myself. The AI has hands on the machine. It's closer to a teammate than a tool at that point.

In practice: I prompt once, define the skills a task needs, and reuse them across scenarios instead of re-explaining from scratch each time. That parallelism is the actual productivity gain — while I'm building a POC for one vulnerability, the agent can be running recon on a second target at the same time. Less of my own time spent context-switching, more happening concurrently.

The guardrail matters as much as the capability. Full, unsupervised machine access for an AI agent is a genuinely bad idea — not hypothetically, just practically, given how easy it is to get lazy about permissions once something is working well. Running it on a disposable VM means if it does go sideways, the fix is deleting the machine, not cleaning up a production environment.

The part most "AI in security" takes skip: it doesn't have the creative jump

Permission friction is real — approving actions one at a time feels like fielding a constant stream of questions from a very capable but literal-minded assistant, and the alternative (broad access) risks burning through actions, and tokens, fast. Output still needs verifying every time; nothing here removes that step. And running this workflow well is as much a management skill as a technical one — you're now responsible for your own work and for checking someone else's, even if that someone else is an AI agent.

But the sharpest limitation isn't about permissions or verification overhead. It's that AI doesn't have the creative jump a human hacker makes. It'll test a site for XSS, but only within the parameter space it's been given — it won't naturally go looking for the deep, unconventional payload structure a human would try specifically because it's unconventional. That's a real gap in offensive security work, where a meaningful chunk of what makes a finding interesting is exactly the part a rules-following process doesn't generate on its own. Trusting an agent's negative result — "nothing found" — without accounting for that gap is how you end up with false confidence, not just false positives.

Where that leaves me

AI is a tool, not a replacement — it speeds up real chunks of the work, from generating an image for a blog post to helping debug code, but the parts of this job that depend on human creativity and judgment aren't going anywhere. I built in the guardrail (isolated VM, gated permissions) because I don't fully trust unsupervised autonomy yet, and I don't think that trust should be assumed by default. The upside is real. So is the reason to keep a hand on the wheel.

I Stopped Chasing OWASP Top 10. Here’s the Bug Bounty Method That Actually Finds Real Bugs

Bijan — Fri, 25 Sep 2026 14:19:00 +0000

A few days ago I jumped back into a bug bounty program after being away for a while.
Like a lot of hunters, I disappear sometimes. When I return, I don’t reinvent the wheel. I open the methodology document I wrote for myself and follow it step by step — recon first, then deeper testing.
The biggest shift in my approach over the years is this:
I don’t treat OWASP vulnerabilities as the priority.
I go after business logic flaws.
Business logic is how the application actually operates — the real flow of value, the process that makes money for the company. Once you understand that flow, you can start looking for ways to break it, bypass steps, or manipulate parameters so the system works in the attacker’s favor instead of the owner’s.
Because of this focus, my recon looks different from the usual “run tools and hope” approach.
Directory brute-forcing rarely helps me. Instead I study the application by using it. I keep Burp Suite open, capture every request and response, and slowly build two things:

A logical mind map of the application — which pages and inputs lead where, how the business process actually moves.
Technical data — exact request structure, headers, parameters, and response behavior.

I map both at the same time. After enough interaction, the potentially dangerous spots start to stand out on their own.
I’ve had multiple cases where I found and reported valid bugs while still in the recon phase — simply because something in the flow looked wrong and I tested it on the spot.
That’s the real value of treating recon as active study instead of passive scanning. You’re not just collecting endpoints. You’re learning how the business works and where it can be broken.

If this way of thinking about bug bounty resonates with you, follow along. I’ll keep sharing the practical methods and mindsets that actually produce results.

Encryption Isn't Enough — You Also Need to Know If Someone Tampered With Your Data

Bijan — Mon, 21 Sep 2026 17:00:00 +0000

Most people think encryption's job is to keep data secret. That's only half the job — and the half it doesn't cover is exactly where a lot of otherwise-careful implementations quietly break.

This is part 4 of a series documenting what I'm learning building CryptoGraphy.

The gap plain encryption doesn't cover

Encryption without a way to detect tampering means an attacker who can intercept your ciphertext can flip bits in it without ever knowing the key. They can't read your plaintext, but they don't need to — depending on the cipher mode, they can sometimes predictably corrupt it, and your system will happily decrypt the tampered ciphertext into garbage, or in worse cases, into something that looks structurally valid but isn't what was actually sent.

Confidentiality answers "can someone read this." It says nothing about "can someone change this without me noticing." Those are two separate guarantees, and you need both.

Why AES-GCM instead of plain AES-CBC

crypto.py uses AESGCM specifically, not plain AES in CBC mode:

from cryptography.hazmat.primitives.ciphers.aead import AESGCM

def encrypt(plaintext: bytes, key: bytes) -> tuple[bytes, bytes]:
    nonce = os.urandom(12)
    aes = AESGCM(key)
    ciphertext = aes.encrypt(nonce, plaintext, None)
    return nonce, ciphertext


def decrypt(ciphertext: bytes, key: bytes, nonce: bytes) -> bytes:
    aes = AESGCM(key)
    return aes.decrypt(nonce, ciphertext, None)

GCM stands for Galois/Counter Mode, and it belongs to a category called AEAD — Authenticated Encryption with Associated Data. In one pass, it does two things at once:

Encrypts the data, so it stays confidential.
Generates an authentication tag, proving the ciphertext wasn't modified after encryption.

That tag is embedded in the output AESGCM.encrypt() returns. When you call decrypt(), the library recomputes and checks that tag before returning any plaintext at all.

What happens when someone tampers with it

Change even a single bit of the ciphertext after encryption, and AESGCM.decrypt() doesn't return corrupted data — it raises an exception and refuses to return anything. That's the actual security property: failure is loud and immediate, not silent and exploitable. A system built on AES-GCM either gets the exact plaintext that was encrypted, or it gets nothing at all. There's no third outcome where it silently accepts tampered data.

Plain AES-CBC doesn't give you this. It'll happily decrypt tampered ciphertext into whatever the tampering produces — corrupted plaintext, or in some poorly-designed protocols, plaintext an attacker had meaningful influence over. CBC gives you confidentiality. It gives you nothing for integrity, and bolting integrity on afterward (encrypt-then-MAC, done correctly) is exactly the kind of extra step that's easy to get subtly wrong if you're rolling it yourself.

Why this distinction matters more than it sounds like it should

"This is private" and "this is private, and I can trust it wasn't touched" sound like a minor wording difference. In practice they're the difference between a system that's vulnerable to bit-flipping and ciphertext manipulation attacks, and one that simply isn't — for free, as a property of the cipher mode you picked, not something you have to remember to bolt on separately.

This is also why AEAD ciphers like AES-GCM (and alternatives like ChaCha20-Poly1305) have become the default recommendation over plain block cipher modes for new designs: they make the "did I remember to add integrity checking" question disappear by folding it into the encryption primitive itself.

The takeaway

Confidentiality and integrity are two different guarantees, and a lot of homegrown or legacy crypto quietly only provides one of them. Picking AES-GCM over plain AES-CBC isn't a performance or convenience choice — it's closing a specific, well-understood gap that shows up in real systems more often than it should.

Next in this series, the last one: why a nonce has to be unique every single time, and what actually happens if you reuse one under AES-GCM — it's worse than you'd expect.

Have you run into a system that had encryption but no integrity check? What ended up happening?

Reading a Mapping That Lives on a Different Contract

Bijan — Mon, 21 Sep 2026 14:12:00 +0000

My last two entries in this series were both about SimpleStorage.sol — a contract that saves data by ID, and a fix for a missing access control check on it. The next step was different in kind, not just in complexity: instead of writing one contract, I needed to write one that deploys and tracks other contracts. A factory.

The problem: my data structure didn't match the pattern I was building on top of

I followed a tutorial for the base factory structure, but I've been customizing every tutorial in this series rather than copying it directly — SimpleStorage.sol uses a mapping and a struct, where the tutorial I originally learned from used an array. That decision paid off when it came to reading a single value out by ID, but it created a real problem once I needed to build a factory on top of it.

The tutorial's factory pattern assumed each deployed contract exposed its data as an array, so pulling a value back out meant array-style indexing. My deployed contracts expose their data as a mapping(uint256 => EntryData), keyed by an ID rather than a position. Reaching into a different, already-deployed contract's mapping — not just my own — and pulling a specific entry back out wasn't something the tutorial covered, because it wasn't built around that data structure.

How I actually worked through it

Before asking for help, I told the AI I was working with directly that I didn't want generated code — I wanted to be walked toward the answer, not handed it. What followed was closer to a Socratic dialogue than a code request: guiding questions rather than a solution, similar to how I used to walk cybersecurity students toward an answer during training rather than giving it to them outright. That process is what produced this function:

// reads from a deployed SimpleStorage contract
function SfGet(uint256 _SimpleStorageDataID, uint256 _ID) public view returns (string memory, address) {
    return ListOfSimpleStorageContracts[_SimpleStorageDataID].DataIdToData(_ID);
}

Breaking down what this actually does

Two separate problems needed solving in this one function, and they're easy to conflate if you haven't hit this pattern before.

First: which contract? The factory can deploy many SimpleStorage instances, tracked in a list — ListOfSimpleStorageContracts — inside factory.sol. _SimpleStorageDataID is an index into that list, selecting which deployed contract instance to talk to. This is a different concept from the ID used inside SimpleStorage itself, even though both are uint256 — one picks a contract, the other picks an entry inside it.

Second: which entry, inside that contract? Once you've selected a deployed instance, _ID is the key into that instance's mapping — the same DataIdToData mapping from the earlier entries in this series. .DataIdToData(_ID) calls the auto-generated getter Solidity creates for a public mapping, but it's being called on a specific deployed contract reference (ListOfSimpleStorageContracts[_SimpleStorageDataID]), not on this contract.

So the function needs two IDs because there are two levels of lookup happening — which contract, then which entry in it — and conflating them is exactly the kind of bug that would silently return the wrong data instead of failing loudly.

Why the return type includes an address

SimpleStorage's ownership check — the access control fix from the last entry in this series — depends entirely on Owner, an address stored per entry. Reading data back out through the factory has to preserve that: the function returns (string memory, address), not just the string. Any caller or contract using this read function to make a decision — say, deciding whether to allow an action based on ownership — needs that address returned accurately alongside the data. Dropping it, or getting the ordering wrong, would quietly break the same access control logic the earlier fix depended on, just one layer further up the call chain.

Check the full factory.sol here

Where this is headed

Factories like this are a common building block once you get past single, standalone contracts — most DeFi protocols run on some version of "one contract deploys and tracks many instances of another." That's the direction I'm heading next: more DeFi-style projects, building on this pattern rather than starting from scratch each time.

Why I Chose Argon2id Over the \"Faster\" Alternatives

Bijan — Mon, 14 Sep 2026 17:00:00 +0000

Argon2id is deliberately slow. That's not a limitation — it's the entire design goal. For key derivation, fast is a vulnerability, not a feature, and understanding why changed how I think about "performance" as a security property.

This is part 3 of a series documenting what I'm learning building CryptoGraphy.

The core trade-off: speed helps the attacker more than you

Derive a key in one microsecond, and an attacker with the right hardware can try billions of password guesses per second against a stolen hash or ciphertext. Every guess is basically free for them. Make derivation slow and memory-hungry, and that same attack — still technically possible — becomes expensive enough to be impractical at scale.

Here's the actual configuration in crypto.py:

def derive_key(master_password: str, salt: bytes) -> bytes:
    return hash_secret_raw(
        secret=master_password.encode("utf-8"),
        salt=salt,
        time_cost=3,
        memory_cost=65536,   # 64 MiB
        parallelism=4,
        hash_len=32,
        type=Type.ID,
    )

memory_cost=65536 means each single derivation attempt requires 64MB of memory. time_cost=3 adds iteration on top of that. Individually these numbers look arbitrary. Together, they're the whole point.

Why memory cost specifically matters

Older key derivation functions like PBKDF2 are fast to attack on GPUs, because GPUs are built for exactly the kind of math PBKDF2 does: massively parallel, low-memory operations. A single high-end GPU can run an enormous number of parallel PBKDF2 guesses simultaneously, because each guess needs almost no memory.

Argon2 breaks that advantage on purpose. By forcing every single guess to allocate and use real memory (64MB, in this config), it caps how many guesses can run in parallel — GPUs have far less memory available per core than a CPU does, so a GPU that could run thousands of parallel PBKDF2 attempts can only run a small fraction of that many parallel Argon2 attempts before running out of memory. This is called being "memory-hard," and it specifically neutralizes the GPU cracking rigs that are the actual hardware attackers use at scale, not a theoretical edge case.

Why "id" specifically, not "i" or "d"

Argon2 actually comes in three variants:

Argon2d — maximizes resistance to GPU cracking, but is vulnerable to certain side-channel timing attacks because memory access patterns depend on the secret input.
Argon2i — designed to resist those side-channel attacks by using data-independent memory access, at some cost to GPU resistance.
Argon2id — a hybrid that runs Argon2i-style access for part of the process and Argon2d-style for the rest, aiming to get meaningful resistance to both attack classes at once.

That hybrid design is why Argon2id is the variant recommended by current guidance (including OWASP's password storage recommendations) over using Argon2i or Argon2d alone — it doesn't maximize either property individually, but it doesn't leave either one badly exposed either.

Tuning is a real trade-off, not a fixed answer

time_cost=3, memory_cost=65536, parallelism=4 aren't universal constants — they're a balance between security and usability. Crank memory and time cost up, and you get stronger resistance to offline cracking, but every legitimate login or decryption also gets slower and heavier on the server or device doing the deriving. Set them too low, and you're back to a derivation cheap enough to attack at scale. There's no single correct number here — it depends on your threat model and what hardware your legitimate users are deriving keys on.

The takeaway

Slow isn't a bug in a key derivation function — it's the mechanism. Argon2id spends real time and real memory on every single derivation specifically so that an attacker has to spend that same cost, multiplied by however many guesses they need to make. That's the trade a KDF is supposed to make, and it's a completely different goal from a general-purpose hash function like SHA-256, which is meant to be fast.

Next in this series: why encryption alone isn't enough, and what AES-GCM adds on top of confidentiality.

If you've tuned Argon2 or bcrypt cost parameters for a real production system, what trade-offs did you land on? I'd like to hear how people are actually setting these in practice.

What a Confusing Line of Solidity Taught Me About Defaults and Security

Bijan — Sun, 06 Sep 2026 12:27:03 +0000

Last night I spent an hour confused about something that should've taken two minutes.

I was writing my first Solidity storage contract — a simple one, SimpleStorage, that saves entries by ID. Coming from years of web app pentesting, SOC work, and red/purple team ops, I'm used to thinking about how systems get broken, not how they're built. So when I declared:

I expected I'd need to explicitly tell Solidity this was permanent — the same way I had to write string memory _StringData for the temporary parameter in my function. I didn't. State variables like that mapping are storage by default, no keyword required. It took a tutorial, a web search, and finally asking AI directly before that clicked.

Small thing. But it's the kind of small thing that matters more here than in most languages I've worked in — because in Solidity, a misunderstanding like that isn't just a bug. It's the difference between "works in testing" and "exploitable in production."

The problem: two things that look similar, aren't

In most languages I've touched, "where does this variable live" is either irrelevant to the syntax or explicit everywhere. Solidity splits the difference in a way that isn't obvious until it bites you:

Inside a function, if you're working with a string, struct, array, or mapping, you have to say whether it's memory (temporary, wiped after the function call) or storage (permanent, written to the blockchain).
At the contract level — where you declare state variables — you don't say anything, because there's only one option. State variables are always storage.

The inconsistency isn't a language flaw. It's that the "choice" only exists in one context. Outside a function, there's nothing to choose between — a state variable's whole purpose is to persist, so Solidity doesn't ask.

Why the default exists

This maps directly to how the Ethereum Virtual Machine actually works. A smart contract has three places data can live:

Location	Lifespan	Cost	Where it's used
`storage`	Permanent, written to the blockchain	Expensive (gas cost scales with writes)	Contract state variables
`memory`	Temporary, exists only during function execution	Cheap	Local variables inside functions
`calldata`	Temporary, read-only	Cheapest	Function input parameters (external calls)

State variables exist specifically so a contract can remember something between transactions — a balance, an owner address, an entry in a mapping. There's no scenario where a state variable would need to be memory, because a memory variable disappears the moment the function returns. So Solidity doesn't make you spell out the obvious. Everything declared at the contract level, outside a function, is storage.

Inside a function, though, the compiler can't guess your intent. You might want a string that's just scratch space for a calculation — memory — or you might be about to write it back into a state variable — storage. That ambiguity is why the keyword is required there and only there.

How it plays out in code

Here's the shape of the confusion, side by side:

// State variable — always storage, no keyword needed
mapping(uint256 => string) public DataIdToData;

// Function parameter — location must be explicit
function addData(uint256 _id, string memory _StringData) public {
    DataIdToData[_id] = _StringData; // copied from memory into storage
}

_StringData lives in memory for the duration of the function call. The moment you assign it into DataIdToData[_id], it's copied into permanent contract storage. Nothing about the syntax announces that copy is happening — you have to already know the mapping is storage and the parameter is memory to see it.

Why this is a security issue, not just a syntax quirk

This is where the pentester instincts kicked back in. Getting storage vs memory wrong isn't cosmetic — it's a documented vulnerability class in Solidity, and it gets worse with structs and arrays.

If you declare a local variable as storage when you meant memory (or the reverse), you're not creating a copy — you're creating a reference to existing storage. Assign a storage pointer to the wrong slot, or leave one uninitialized, and you can end up writing to state you never meant to touch. This general class of bug — storage layout confusion, particularly around delegatecall and library contracts — is widely cited in postmortems of real incidents, including the 2017 Parity multisig wallet freeze, where a storage layout issue tied to a library contract left funds permanently inaccessible. I'm citing that as a well-known industry example, not something from my own contract — but it's exactly the category of mistake that starts as "wait, which one is this again?"

That's the pattern I keep running into three weeks in: things that would be a minor bug in a web app are a fund-draining or fund-freezing bug on-chain, because there's no "restart the server and it's fine" — the mistake is written to the chain.

What I'm taking from this

I've been studying Solidity for about three weeks now, doing it in the opposite order from how I originally learned security: build first, then go back and audit. It's blockchain, smart contracts, tokens, and a syntax that reads like a mix of Python, C++, and PHP — simpler than I expected, but with sharper edges than I'm used to.

The practical habit I'm building from this: whenever Solidity doesn't make me declare something, I now ask why not, instead of assuming it's not important. The implicit defaults are often exactly where the design decisions — and the risk — are concentrated.

If you've made the same shift — from finding vulnerabilities to writing the code that creates them — what tripped you up first? What resources actually moved the needle for you when you were starting out?

The One Line of Code That Stops Rainbow Table Attacks

Bijan — Wed, 02 Sep 2026 17:00:00 +0000

Someone steals a database of password hashes. Instead of cracking each one individually, they check it against a rainbow table — a massive precomputed list mapping hashes to the passwords that produced them. If a stolen hash shows up in that table, they're done in milliseconds. No cracking required, just a lookup.

Salting kills this attack entirely, and it's a small enough fix that it's worth understanding exactly why it works rather than just knowing "you're supposed to do it."

This is part 2 of a series where I'm documenting what I'm learning building CryptoGraphy, a small Python project I'm using to actually understand applied cryptography instead of just calling library functions.

What a salt actually does

In main.py, before any key derivation happens, a fresh random salt is generated:

import os

salt = os.urandom(16)
key = derive_key(password, salt)

That salt gets fed into Argon2id alongside the password:

def derive_key(master_password: str, salt: bytes) -> bytes:
    return hash_secret_raw(
        secret=master_password.encode("utf-8"),
        salt=salt,
        time_cost=3,
        memory_cost=65536,
        parallelism=4,
        hash_len=32,
        type=Type.ID,
    )

The effect: two users with the identical password get two completely different derived keys, because their salts are different. Same input password, different salt, unrelated output.

Why this specifically defeats rainbow tables

A rainbow table only works because it's precomputed once and reused against every hash in a stolen database. That only makes economic sense if the same password always produces the same hash — precompute "password123" → its hash one time, and that entry is useful forever, against any system, any user.

Add a per-user salt, and that assumption breaks. Now "password123" with salt A produces a completely different output than "password123" with salt B. An attacker would need to precompute a separate rainbow table for every possible salt value, which — with a 16-byte random salt — is computationally meaningless to attempt. You've turned one attack that scales across every victim into an attack that has to be redone, from scratch, per victim.

The salt isn't secret — and that's fine

This is the detail that trips people up: the salt in main.py isn't hidden anywhere. It's meant to sit right next to the ciphertext (or the stored hash) in plain sight, and that's by design.

The salt's job was never to be a secret. Its job is to guarantee uniqueness — that no two derivations, even of the same password, ever produce the same result. Secrecy is the key's job. Uniqueness is the salt's job. They're different properties solving different problems, and a salt doesn't stop doing its job just because an attacker can see it.

Why this is easy to skip and expensive to skip

Skipping the salt costs you nothing while you're learning — the code still runs, the demo still works, the tests still pass. It's only expensive once real data is at stake, because "storing unsalted hashes" is one of those failures that's invisible until a breach happens, at which point it turns an already-bad leak into a catastrophic one: every user with a common password becomes crackable in bulk, instantly.

The takeaway

One os.urandom(16) call, fed into key derivation, is the difference between "a leaked database is a slow, per-user cracking problem" and "a leaked database is a five-minute rainbow table lookup." It's a genuinely small piece of code carrying a genuinely large amount of the actual security guarantee.

Next in this series: why I specifically chose Argon2id over faster alternatives like PBKDF2 — and why "slow" is the entire point of a key derivation function.

Have you dealt with a real system that turned out to be storing unsalted hashes? Curious how that played out.

DEV Community: Bijan

The oracle problem

I Gave My SOC Experience to AI. It Gave Me Sigma Rules.

You don't know how to work!

I Found an Access Control Bug in My First Solidity Contract

The fix

address(0) isn't just a default

The Line of Code That Makes Every Encryption Unique — Even With the Same Password

Why identical ciphertext for identical plaintext is a real problem

Where the nonce comes in

The nonce doesn't need to be secret — it needs to never repeat

What actually happens if you reuse one

Why "generate it fresh, every call" is the whole mitigation

The takeaway across this whole series

I Gave AI Hands on a Virtual Machine — Here's What Changed

I Stopped Chasing OWASP Top 10. Here’s the Bug Bounty Method That Actually Finds Real Bugs

Encryption Isn't Enough — You Also Need to Know If Someone Tampered With Your Data

The gap plain encryption doesn't cover

Why AES-GCM instead of plain AES-CBC

What happens when someone tampers with it

Why this distinction matters more than it sounds like it should

The takeaway

Reading a Mapping That Lives on a Different Contract

The problem: my data structure didn't match the pattern I was building on top of

How I actually worked through it

Breaking down what this actually does

Why the return type includes an address

Where this is headed

Why I Chose Argon2id Over the \"Faster\" Alternatives

The core trade-off: speed helps the attacker more than you

Why memory cost specifically matters

Why "id" specifically, not "i" or "d"

Tuning is a real trade-off, not a fixed answer

The takeaway

What a Confusing Line of Solidity Taught Me About Defaults and Security

The problem: two things that look similar, aren't

Why the default exists

How it plays out in code

Why this is a security issue, not just a syntax quirk

What I'm taking from this

The One Line of Code That Stops Rainbow Table Attacks

What a salt actually does

Why this specifically defeats rainbow tables

The salt isn't secret — and that's fine

Why this is easy to skip and expensive to skip

The takeaway

`address(0)` isn't just a default