DEV Community: Ksatria Bintang Samudra

Social engineering: the easiest hack is still a conversation

Ksatria Bintang Samudra — Thu, 22 Oct 2026 14:10:00 +0000

I can spend a week probing your firewall and find nothing. Or I can call your front desk, sound confident, and have someone reset a password for me in four minutes.

Guess which one attackers reach for first.

The hardest system to patch is not your server. It is the person who answers the phone.

The weakest link has always been human

Kevin Mitnick was once the most wanted computer criminal in America. He was arrested in 1995, he did his time, and then he spent the rest of his life, until he died in 2023, as a security consultant teaching companies how he had done it.

Here is the thing people miss about Mitnick. He was a skilled technician, but his favorite tool was a telephone. He wrote an entire book about it, "The Art of Deception." Again and again he found it easier to talk a human into giving him access than to break the machine. He would learn a company's internal lingo, sound like he belonged, and simply ask. People helped him, because helping is what good employees do.

That is the uncomfortable core of social engineering. It does not attack a flaw in your code. It attacks a feature in your people. Helpfulness. Trust. The instinct to not make a fuss.

The buttons they push

I am not going to hand you a manipulation manual. That is not what this is for. But you cannot defend against something you cannot recognize, so here are the levers, named plainly.

Authority. A voice claiming to be IT, the CEO, your bank, a government office. We are trained from childhood to comply with authority, and an attacker wears it like a costume.

Urgency. "The account will be locked in ten minutes." "The wire has to go out now." Panic shuts down the part of your brain that asks good questions. That is the entire point of the rush. If someone is manufacturing a crisis, the crisis itself is the tell.

Familiarity. They have done homework. They know your manager's name, a project you are on, a vendor you actually use. A little real detail makes a fake story feel true.

None of this needs a single line of code. The 2020 Twitter breach, where high-profile accounts were hijacked, started with attackers phoning employees and talking their way into internal tools. In 2023, major casino companies were wrecked after attackers simply called the IT help desk and convinced it to hand over access. These are not movie plots. This is Tuesday.

How to not get got

The good news is that the defense is also human, and it is simple. It just has to be practiced.

Verify out of band. If "the bank" calls you, hang up and dial the number on the back of your card. If "the CEO" emails asking for an urgent transfer, message them on a channel you already trust. The real one will never be angry that you checked.

Never trust caller ID. This is the big one. Spoofing the number that shows up on your screen is trivial, ancient technology. That familiar name on the display proves nothing at all. Treat it as a claim, not a fact.

Slow down when someone rushes you. Urgency is the fingerprint of almost every scam. The moment you feel pushed to act right this second, that feeling is the alarm going off. Stop and verify precisely because it feels urgent.

And here is the most important one, the one that is really about leadership and not technology. Build a culture where it is okay to double-check. Where the help desk can say "let me call you back to confirm" without getting yelled at. Where a junior can question a request from someone senior and get thanked, not punished. Most social engineering succeeds because people are more afraid of being rude than of being wrong.

The strongest firewall in your whole company is an employee who feels safe saying "let me verify that first."

You can buy the best security tools on earth. None of them pick up the phone. That is still a person. So train the person, protect the person, and give them explicit permission to be suspicious.

The easiest hack was never the code. It was always the conversation.

I am Ksatria Bintang Samudra, an AI-native full-stack engineer with a penetration-testing background and a deep interest in digital forensics, open to remote work worldwide. More of what I build at ksatriabintangsamudra.com.

Phishing and BEC: The Attack That Skips Your Code

Ksatria Bintang Samudra — Wed, 21 Oct 2026 02:50:00 +0000

You can write perfect code. Parameterized queries, escaped output, a locked-down CSP, the whole kit. And an attacker can still walk straight past all of it by sending one email to your finance team.

That is the uncomfortable truth about phishing and Business Email Compromise. They do not attack your code. They attack your people. And people are patchable only up to a point.

The attack that skips your stack

Phishing is impersonation at scale. An email, a text, a message that looks like it came from someone you trust. Your bank. Your boss. A vendor you pay every month. It points you to a fake page that looks real, and asks you to log in or approve something. You hand over the keys yourself.

Business Email Compromise is the sharpened, targeted version. No mass spam. The attacker studies one company, learns who pays the invoices and who signs off on them, then impersonates an executive or a supplier and asks for a wire transfer or a change of bank details. It is quiet, specific, and it is aimed straight at your money.

How it actually works

Strip away the surface and every one of these runs on the same three levers.

Impersonation. The message wears a face you already trust: a name, a logo, a spoofed or lookalike domain that sits one character off from the real one.

Urgency. "The deal closes in an hour." "The CEO needs this wired before the board call." "Your account will be locked." Panic is the point. A rushed brain stops checking details.

A believable ask. Reset your password here. Update the vendor's bank account. Approve this invoice. Buy these gift cards. Nothing that feels insane in the moment, which is precisely why it works.

No exploit. No malware required. Just a human who trusted the wrong email on a busy day.

The numbers are absurd

This is not a small problem. According to the FBI's Internet Crime Complaint Center, BEC accounted for more than 50 billion dollars in exposed losses worldwide between late 2013 and the end of 2022. Fifty billion. From emails.

BEC lands year after year as one of the costliest categories of cybercrime the FBI tracks. It outruns flashy ransomware in raw dollars, and it does it with no code at all, just a convincing message and a wire transfer that cannot be clawed back once it clears.

Why smart people fall for it

Because it is not about intelligence. It is about context. The email arrives when you are busy, it matches a process you genuinely do every week, and it pushes a button wired deep into us: respond fast when the boss asks.

I have a security background, and I will tell you honestly, a well-made BEC email on a bad day would still earn a second of doubt from me. Anyone who claims otherwise has not seen a good one.

The defense is a phone call

The fixes here are mostly not technical. They are habits.

Verify out of band. Got a payment request or a bank-detail change? Call the person on a number you already have, never the one printed in the email. This single habit kills most BEC.
Turn on MFA everywhere. If a password gets phished, a second factor is the wall still standing.
Slow down. Urgency is the weapon. The pause to check is the shield. Real emergencies survive a two-minute verification. Scams usually do not.
Lock the money path. Require dual approval for wire transfers and for any change to vendor banking details.
Harden your domain with SPF, DKIM, and DMARC so attackers cannot spoof your name quite so easily.

Your firewall cannot read tone. Your WAF cannot sense urgency. The last line of defense against this one is a calm human who picks up the phone before they move the money. Be that human.

Rate Limiting Is the Cheapest Security You Are Not Using

Ksatria Bintang Samudra — Tue, 20 Oct 2026 13:50:00 +0000

Quick question. How many times can someone hit your login endpoint in one minute? If your honest answer is "I don't know" or "as many as they want," I have some bad news and one very easy fix.

I spent years on the offensive side, testing other people's apps. Here is a pattern I saw again and again: the app was clever, the code was clean, and the front door had no limit on how many times you could knock. Unlimited requests is not a feature. It is an open invitation.

Rate limiting is the cheapest, highest-leverage security control most teams still skip. Let me convince you.

What unlimited endpoints actually invite

An endpoint with no limit is a megaphone handed to anyone who finds it.

Brute force. A login with no throttle lets someone try thousands of passwords against one account. Hand them a leaked password list and that becomes credential stuffing, and it works more often than you would like, because people reuse passwords everywhere.

Resource exhaustion. Your expensive endpoints, search, report generation, anything that leans hard on the database, can be hammered until the whole app falls over. That is a denial of service that costs the attacker almost nothing and costs you your uptime.

And the modern nightmare: the bill. If your endpoint quietly calls a paid API behind the scenes, an AI model, an SMS gateway, a geocoding service, then every unlimited request is money leaving your account. I have seen a single unprotected endpoint turn into a four-figure invoice over a weekend. The attacker never even broke in. They just kept asking.

It is cheap because it is simple

Here is why I call it the cheapest security you have: the mental model is trivial. Count requests. If a client crosses the line inside a time window, say no.

That is it. A few lines of config standing in front of real damage. No machine learning, no threat intelligence feed, no six-figure vendor contract. You are just refusing to let one client speak louder than all the rest combined.

And because it is so simple, there is no excuse to postpone it. This is the control you add on a Tuesday afternoon and quietly forget about, right up until the day it saves you.

Where to put the limits

You do not need to protect everything equally. Spend your effort where abuse actually hurts.

Auth routes first. Login, signup, password reset, token endpoints. These are the ones people attack, so these get the tightest limits. A handful of attempts per minute per IP and per account is plenty for a real human and painful for a bot.

Then anything expensive or paid. Every endpoint that costs you money or heavy compute gets a budget, per user, per key, per IP.

Everything else gets a sane global default, so one misbehaving client cannot drown out the rest.

Do it the easy way

You almost certainly do not need to build this from scratch.

Your reverse proxy already does it. Nginx has limit_req. Your API gateway and your CDN, Cloudflare and friends, can throttle before traffic ever touches your server, which is the best possible place to stop a flood. Inside the app, reach for a maintained middleware and back it with Redis so your limits hold across every instance. A fixed window is fine to start. A token bucket is nicer when you want to allow short, honest bursts.

Two details that matter. Return a proper 429 Too Many Requests with a Retry-After header so honest clients back off politely. And log when limits trip, because a spike in rejections is often your earliest warning that someone is probing you.

Here is the whole thing in one sentence: a request you refuse to answer cannot brute force you, cannot drain your database, and cannot run up your bill.

Unlimited was never generosity. It was just a door you forgot to put a lock on.

One Password Shut Down a US Fuel Pipeline

Ksatria Bintang Samudra — Mon, 19 Oct 2026 01:20:00 +0000

In May 2021, Americans were filling plastic bags with gasoline. Panic buying. Lines wrapped around the block. A regional state of emergency declared. Not because of a storm or a war, but because one VPN account, guarded by a single password and no second factor, got used by the wrong people.

Colonial Pipeline moves close to 45 percent of the fuel consumed on the entire US East Coast. On May 7, 2021, the ransomware group known as DarkSide got into Colonial's network. The company shut the pipeline down on its own. And a huge slice of a continent's fuel supply simply stopped moving.

It started with a single password

Here is the detail that should make every engineer physically wince. The attackers did not need a zero-day or some custom exploit. Investigators traced the entry back to one compromised VPN credential. A single account. The password was reportedly found inside a batch of leaked credentials, the kind that surfaces when people reuse the same password across services and one of those services gets breached somewhere else entirely.

That account was not even in active use anymore. But it was still enabled. And, critically, it had no multi-factor authentication in front of it. One password, and the door swung open.

I have written this line into nearly every security review I have ever delivered, and I will write it here too. MFA on that one forgotten account would very likely have stopped the entire incident. Not a million-dollar appliance. Not an AI defense platform. A second factor. The cheapest, most boring control we have in the entire toolbox.

Why shut the whole pipeline down?

Plenty of people asked why a fuel company would halt physical operations over a computer intrusion. The ransomware mainly hit the IT and billing side, not the industrial control systems directly. But Colonial could not reliably bill for fuel, and far more importantly, could not be certain how far the attackers had actually spread. When you cannot draw a clean, confident line between your compromised office network and the systems that run physical, flammable infrastructure, you stop everything. You assume the worst case. That is genuinely the responsible call, and it also quietly reveals how thin that boundary really was.

The ransom, and the plot twist

Colonial paid. Roughly 4.4 million dollars in Bitcoin, handed to DarkSide in exchange for decryption tools and an end to the pain. Here is the twist most people forget. About a month later, the US Department of Justice announced it had clawed back a large chunk of the money, somewhere around 2.3 million dollars, by tracing the cryptocurrency and seizing the wallet it flowed into. It turns out the blockchain that everyone loves to call "anonymous" is a permanent, public, searchable ledger. Funny how that detail only seems to matter to the criminals afterward.

The lesson nobody wants to hear

I come from the offensive side of this work, and honestly this breach is almost insulting in how simple it was. No elite tradecraft. No genius. A valid login on an abandoned account with no MFA, pointed at a company whose uptime an entire region quietly depends on.

The scale of the damage had almost nothing to do with the sophistication of the attack. It had everything to do with how brittle the target already was underneath. Critical national infrastructure sat one leaked password away from a real fuel crisis, and I would bet the attackers could not believe their own luck.

So yes, patch your systems. But before that, go turn on MFA absolutely everywhere, and go disable the accounts that nobody uses anymore. The boring cleanup list is exactly where the breaches live.

A nation's gas pumps ran dry because somebody, somewhere, reused a password. Let that single sentence be the whole security awareness training.

Zero Trust, explained without the buzzwords

Ksatria Bintang Samudra — Sun, 18 Oct 2026 15:30:00 +0000

"Zero Trust" might be the most abused phrase in security. Every vendor slaps it on a box and charges you extra for it. Let me strip the marketing off and tell you what it actually means, because underneath the noise there is a genuinely good idea.

The castle was always a lie

The old model is called "castle and moat." You build a strong perimeter, a firewall, a VPN, and everything inside is trusted. Outside is scary. Inside is family.

It sounds reasonable. It is also why so many breaches get so bad.

Here is what happens. An attacker phishes one employee. One laptop. Now they are inside the castle, and the castle was built on the assumption that everyone inside is friendly. So they move sideways, from the one machine they own to the file server, to the database, to the backups. The moat does nothing once someone is standing in the courtyard.

The perimeter stopped making sense anyway. Your apps live in the cloud. Your people work from cafes and bedrooms. Your "inside" is spread across three continents and a dozen SaaS tools. There is no moat anymore. There is just the internet, and you are on it.

Never trust, always verify

Zero Trust was named by John Kindervag at Forrester around 2010, and the US standards body NIST later wrote it up properly in a document called SP 800-207. You do not need to read it tonight. You need the core idea.

Stop trusting the network. Trust nothing based on where it happens to be sitting.

Every request, every time, gets verified on its own merits. Who are you? What device is this? Are you allowed to touch this specific thing right now? A request from inside the office gets the same suspicion as one from a random coffee shop, because the office network is not proof of anything.

Three ideas hold the whole thing up.

Verify explicitly. Authenticate and authorize every request based on identity, device health, and context. Not location. Never just location.

Least privilege. Give every person and every service the minimum access they need to do the job, and nothing more. The marketing intern does not need production database access. Your logging service does not need write access to everything you own.

Assume breach. Operate as if an attacker is already inside, because one day they will be. Segment your systems so one compromised account cannot reach everything. Log aggressively. Make lateral movement hard and loud.

Google did exactly this for real after a serious attack around 2009, in a project called BeyondCorp. They threw out the privileged internal network entirely. Their employees now authenticate the same way whether they are in the building or sitting in an airport.

You do not need a million-dollar budget

This is where people tune out. They think Zero Trust is an enterprise thing, a procurement thing. It is not. It is a mindset, and a small team can start living it this week.

MFA on everything, no exceptions, especially your cloud console and your git host. That single move is the highest-value thing on this list.

Least privilege by default. Audit who has admin. Most of them do not need it. Use short-lived credentials and scoped tokens instead of permanent keys rotting in someone's env file.

Stop treating the VPN as a magic trust badge. A device being "on the network" should grant it nothing by itself.

Log what matters, and actually look at it. You cannot assume breach if you would never notice one.

Treat every internal service as if it might be the compromised one. Internal APIs still authenticate. Service accounts still get scoped down.

The real shift

Zero Trust is not a product you buy. Anyone selling it to you that way is selling you a firewall with a fresh sticker.

It is a change in the default answer. The old default was "you are inside, so you are trusted." The new default is "prove it, every time." That is the whole philosophy. Everything else is implementation detail.

Trust is not a location. It never was.

XSS: When Your Own Site Runs the Attacker's Code

Ksatria Bintang Samudra — Sat, 17 Oct 2026 02:05:00 +0000

Cross-site scripting is a strange kind of betrayal. Your site, the one your users trust, turns around and runs the attacker's code inside their browser. Not your server. Their browser. Their session. Their logged-in tab.

And the browser has no reason to be suspicious. The script arrived from your domain, wrapped in your padlock, under your name. So it runs with all the trust your users handed you.

That is XSS in one breath. Let me slow it down.

The concept: output you forgot to escape becomes code

A browser reads HTML and runs any script it finds inside it. That is its entire job.

XSS happens when attacker-controlled text lands in your page without being treated as plain text. You meant to display a comment, a username, a search term. But you dropped it straight into the HTML, so the browser cannot tell the difference between the words you wanted to show and a script someone slipped in. If the input contains markup, the browser runs it.

Input becomes output becomes code. Same shape as SQL injection, different stage. There the database gets tricked. Here it is the browser.

Stored versus reflected, quickly

Two flavors you should know.

Reflected XSS bounces off a single request. The malicious input rides in on a crafted link or form, the server echoes it straight back into the response, and it fires for whoever clicked. It is a trap you have to lure someone into.

Stored XSS is worse. The payload gets saved. A comment, a profile bio, a support ticket. It sits in your database and fires for every single person who loads that page. One poisoned comment, thousands of victims. No link required.

There is a third kind, DOM-based, where the whole thing plays out in client-side JavaScript that writes untrusted data into the page. Same root cause. Untrusted data, trusted context.

What an attacker actually does with it

This is where people stop taking it seriously, so let me be blunt.

Once attacker script runs in your user's browser, it can read whatever that browser can. It can lift session tokens and ride in as that user. It can quietly rewrite the page, drop a fake login form over the real one, and harvest whatever gets typed. It can deface the site. It can act on the user's behalf, click their buttons, change their email, all while looking exactly like them.

Session theft is the big one. If a script can read the session, it can become the user. Game over, no password required.

The fix: escape, frameworks, CSP

Good news. We know how to stop this.

Escape output based on context. Text going into HTML gets HTML-encoded, so markup renders as harmless characters instead of running. This is the core defense.
Lean on your framework. React, Vue, and Angular auto-escape by default. Render user text the normal way and they turn it into text, not code. Use that behavior on purpose.
Set a Content Security Policy. CSP is your safety net, a header that tells the browser which scripts are allowed to run. Even if something slips through, a tight policy can stop it from executing.
Set HttpOnly on session cookies so client-side script cannot read them. That alone takes the most common session-theft path off the table.

The footguns

Here is where teams quietly reintroduce it. Every framework has an "I know what I am doing" door. In React it is dangerouslySetInnerHTML. In plain JavaScript it is innerHTML. The name is a warning, not a suggestion.

The moment you push raw, unescaped user content through one of those, every auto-escape protection you had is gone. If you genuinely must render user-supplied HTML, sanitize it first with a trusted, maintained library. Never trust it raw.

Your framework escapes by default for a reason. The day you switch that off, you had better be certain the input is clean. Because the browser will run whatever you give it, and it will never ask whose side it is on.

Stop Committing Your API Keys (A Love Letter to .env and Secret Managers)

Ksatria Bintang Samudra — Fri, 16 Oct 2026 12:40:00 +0000

I want to tell you about the worst thirty seconds of a developer's week. You push a commit. Your phone buzzes. It is an automated email from your cloud provider: "unusual activity detected." Someone found your key, spun up a fleet of GPU instances to mine crypto, and you now owe thousands of dollars.

I have watched this happen to real people. It is never a movie villain. It is a key that should never have been in the code in the first place.

So let me write the love letter your secrets actually deserve.

Why secrets leak (it is always the same three doors)

Secrets do not escape through some exotic hack. They walk out through doors you left open.

Door one: git history. You committed a key, deleted it in the next commit, and now you think it is gone. It is not. It is sitting in the history forever, and bots scan fresh public pushes within seconds looking for exactly this. Deleting the line does nothing. The history remembers everything.

Door two: the client bundle. Anything in your frontend JavaScript is public. I can open dev tools and read it. That "secret" key baked into your React app? Every visitor can see it. If the browser can read it, it was never a secret.

Door three: the human stuff. A key in a screenshot on a bug report. A token pasted into a Slack channel. A .env file emailed "just this once." Secrets have a talent for ending up exactly where you least expect them.

What a leaked key actually costs

People underestimate this because the key feels small. It is not small.

A leaked payment key can drain real money. A leaked cloud key can run up a five-figure bill overnight, and good luck getting that refunded. A leaked database credential can expose every user you have, and now you are not debugging, you are writing a breach disclosure and talking to lawyers.

One string. That is all it takes. The blast radius of a forgotten key is almost never proportional to how careless it felt in the moment.

How to do secrets right

Here is the part I actually love, because the fix is genuinely easy.

Keep secrets in environment variables, loaded from a .env file locally. Then add .env to your .gitignore before you write a single key into it. Commit a .env.example with empty placeholders so your teammates know what to fill in, without ever shipping the real values.

For anything past a side project, graduate to a real secret manager. AWS Secrets Manager, Vault, Doppler, your platform's built-in store, pick one. They give you access control, audit logs and rotation in one place. Your app reads the secret at runtime. It never lives in the repo.

Rotate on a schedule, and rotate immediately the moment a key is exposed. A rotated key is a dead key, and a dead key cannot bill you.

Build a net, not just good intentions

Discipline fails. People are tired, deadlines are real, keys slip through. So automate the safety net.

Add a secret scanner to your pipeline. Tools like gitleaks or trufflehog, plus GitHub's own push protection, will catch a key before it ever lands. Run it as a pre-commit hook so the key gets blocked on your machine, not discovered on someone else's.

And if you do leak one, do not just delete the commit. Rotate the key first, then clean up. The order matters. The exposed key is the emergency, not the tidy git history.

Your secrets are the keys to the whole building. Stop leaving them under the doormat and taping a spare to the front window.

Target Got Breached Through Its Air Conditioning Vendor

Ksatria Bintang Samudra — Thu, 15 Oct 2026 03:10:00 +0000

The crew that stole around 40 million card numbers from Target did not break into Target. Not at first. They broke into the company that kept Target's stores cool.

In late 2013, a refrigeration and HVAC vendor called Fazio Mechanical Services got phished. The attackers lifted that vendor's network credentials, the login Target had issued so the contractor could do things like submit invoices and handle remote monitoring. From the foothold of a heating-and-cooling contractor, the attackers pivoted inward. And they kept pivoting, patiently, until they reached the point-of-sale systems sitting at the checkout registers.

Nobody guards the side door

This is the part that gets me, as someone who spent years hunting for ways into networks. Everyone fortifies the front door. The login page, the public web app, the customer-facing surface. That is where the security budget flows, because that is what feels like "the perimeter" on a whiteboard.

Meanwhile a heating contractor is walking around with a live credential into your network, and half the time the security team cannot even tell you that account exists. The front door had a vault with a retina scanner. The side door, the one for the guy who services the air conditioning, had a sticky note with the password on it.

Attackers are not romantic about any of this. They do not care how they get in. They will take the vendor, the intern, the forgotten test account, the stale API key, whatever happens to be cheapest and softest that week.

40 million cards, during the worst possible week

The timing was almost elegant, if you can stomach using that word. The malware landed on Target's POS terminals right as the holiday shopping season hit full throttle. Every time a customer swiped a card at a register, the malware scraped the card data straight out of memory, in the brief window before it was encrypted, and quietly shipped it back out to the attackers.

By the time it was contained, around 40 million payment cards were compromised, and personal information for as many as 70 million customers was swept up alongside them. The CEO eventually resigned. The settlements and cleanup ran into the hundreds of millions of dollars. All of it starting from one phished air-conditioning firm in the supply chain.

Your network is only as segmented as your worst vendor

Here is the lesson that actually matters, and it is architectural, not another phishing-awareness poster. A vendor account meant for facilities monitoring should never, by any sane law of network design, be able to reach the machines that process credit cards. Those two systems should live in completely separate worlds. The real failure was that a path existed at all from one to the other. The phishing was just the match. The flat, poorly segmented network was the gasoline it landed in.

If a contractor's login can quietly traverse your environment all the way to the crown jewels, you do not have a vendor problem. You have an architecture problem wearing a vendor costume.

The question I ask every client now

So on every engagement now, I ask one deliberately annoying question early. "Who else has access to this network that does not actually work here?" Vendors. Integrations. That handy SaaS tool holding an API key. The managed service provider. The payment processor. Each one is a door into your house, and each door needs its own lock, its own camera, and a real wall between it and anything you would hate to lose.

Least privilege is not a buzzword to nod at in a meeting. It is the concrete difference between losing one air-conditioning vendor and losing 40 million of your customers' cards.

Your security is not the height of your tallest wall. It is the strength of your weakest vendor, and I would bet you have not thought seriously about that one in a year.

The password is dying. Here is what is killing it.

Ksatria Bintang Samudra — Wed, 14 Oct 2026 14:20:00 +0000

I test systems for a living, with permission, and I will let you in on a secret. The flashy exploits you see in movies are rare. Most of the time I do not break the lock. I just walk in with a key someone already lost.

That key is a password. And the password is dying. Good.

Why passwords fail

A password is a shared secret. You know it, the server knows it. The whole model falls apart the moment anyone else learns it, and someone always does.

Three things kill passwords, over and over.

Reuse. Be honest with yourself. You have one "good" password with a number on the end, and you use it in ten places. When one of those sites gets breached, attackers take the leaked list and try it against your email, your bank, your GitHub. This is called credential stuffing. It is cheap, automated, and brutally effective.

Leaks. Have I Been Pwned tracks billions of compromised accounts. Billions. Your password is probably sitting in one of those dumps right now, from some forum you forgot about in 2015.

Phishing. A password is just text. If I can trick you into typing it into a page that looks like your bank, I have it. No malware, no zero-day. Just a convincing login box and one moment of your inattention.

Year after year, Verizon's breach report puts stolen credentials and the human element at the center of most incidents. We have known this for a decade. We kept shipping password fields anyway.

MFA helped, but it is not the finish line

Two-factor authentication was the obvious patch. Add a second thing. A code, a push, a text.

It raised the bar, and you should absolutely turn it on today. But let us not pretend it is bulletproof.

SMS codes can be stolen through SIM swapping, where an attacker talks your carrier into moving your number to their own phone. One-time codes from an authenticator app are better, but they can still be phished in real time. I send you to a fake page, you type your six digits, I relay them to the real site within seconds.

And push notifications? Attackers just spam you with prompts until you tap "approve" out of sheer exhaustion. That is how attackers got into Uber in 2022. MFA fatigue is a real attack, not a theory.

The problem is the same every time. If a human can read a secret and type it somewhere, a human can be tricked into typing it somewhere wrong.

Passkeys change the game

This is the part I am genuinely excited about.

Passkeys are built on the FIDO2 and WebAuthn standards from the FIDO Alliance and the W3C. Instead of a shared secret, your device generates a cryptographic key pair. The private key never leaves your phone or laptop. The site only ever stores the public half, which is useless to a thief.

When you log in, your device signs a challenge. There is no secret to phish, no code to relay, nothing to leak in a database dump.

Here is the part that matters most to me. A passkey is bound to the real site's domain. If you land on a lookalike phishing page, your device simply will not sign. It does not get fooled by a convincing login box, because it never trusted the box in the first place. It trusted the math.

Apple, Google, and Microsoft all support passkeys now, synced through their keychains. The friction that killed every past attempt at going passwordless is finally gone.

What developers should actually do

Stop treating this as a someday problem.

Turn on MFA for everything you own, and prefer an authenticator app or a hardware key over SMS. For the apps you build, add WebAuthn and offer passkeys as a first-class login option, not a setting buried three menus deep. Check new passwords against breach lists like the Pwned Passwords API. Retire SMS as a primary factor wherever you can.

We spent thirty years asking humans to be perfect secret-keepers. They never were. The fix was never a longer password or one more special character. It was removing the secret entirely.

The password is dying. Help it along.

SQL Injection: The Bug That Refuses to Die

Ksatria Bintang Samudra — Tue, 13 Oct 2026 01:45:00 +0000

SQL injection is older than some of the engineers shipping it today. It was written up publicly back in 1998. It is still sitting on the OWASP Top Ten. Let that sink in. We have had more than two decades to kill this bug, and it is still in production, right now, inside apps people trust with their money.

I have a penetration-testing background. SQL injection is often the first thing I reach for on a login form, not because I am clever, but because it still works far too often.

Let me explain the concept, because once you see it you cannot unsee it.

Your query is a sentence, and user input is a word in it

A database query is just a command written in a language called SQL. "Give me the user whose email matches this." Simple enough.

The trouble starts when a developer builds that command by gluing strings together. They take the sentence, cut a hole where the user's input goes, and paste whatever the user typed straight into the hole.

Here is the mental model. The database does not know where your trusted sentence ends and the user's untrusted input begins. To the database, it is all one string. One command. So if an attacker types something that reads like SQL instead of reading like a name, the database happily treats it as part of the command.

That is the whole trick. Input that was meant to be data gets executed as code. The user stopped answering your question and started giving the database new orders.

I will not hand you a working payload. You do not need one to understand the danger. Just picture a login box where the "password" field quietly rewrites the question from "is this password correct" into "log me in no matter what." Same mechanism. Different sentence.

Why it refuses to die

Because string concatenation feels natural. You need a dynamic query, you have a variable, you add them together. It reads fine. It passes a code review from someone who is tired. It works perfectly in testing, because testers type names, not commands.

It also hides in the boring corners. An old reporting endpoint. A search filter someone bolted on during a Friday rush. A legacy service nobody wants to touch. The shiny new parts of your stack are usually fine. The ten-year-old admin panel is where I go hunting.

The fix is boring, and boring is good

Parameterized queries. Also called prepared statements. This is the one that matters.

Instead of gluing input into the sentence, you send the command and the data separately. You tell the database, "here is the query, and here are the values, and the values are values, do not read them as commands." The database keeps the two apart. The hole is sealed. Input can never cross back into code.

In practice:

Use parameterized queries or prepared statements everywhere. No exceptions for "just this one small query."
Let a mature ORM build your queries for you. They parameterize by default.
Never concatenate user input into a query string. Not for ids. Not for sort order. Not ever.
Apply least privilege to the database account, so one mistake stays contained.

ORMs help, until you hand them a loaded gun

Here is the part people miss. An ORM protects you right up until you drop into its raw-query escape hatch and start concatenating again. Most ORMs have one. Most teams use it. That raw string is exactly where the injection sneaks back in.

So the rule holds even inside your safe framework. Pass values as parameters. If you find yourself building a query by adding strings together, stop, no matter which tool you are in.

SQL injection is not a hard problem anymore. The fix has existed for as long as the bug has. We keep shipping it because we keep taking the shortcut. Write the parameterized query. It costs you three extra seconds, and it is the difference between a database and a crime scene.

How I'd Secure Your SaaS in a Weekend

Ksatria Bintang Samudra — Mon, 12 Oct 2026 13:15:00 +0000

Your SaaS is live. Users are paying. And somewhere in the back of your head a small voice keeps whispering: is any of this actually secure?

Good. That voice is right to be nervous.

I come from penetration testing. For years my job was to find the one door you forgot to lock. Here is the uncomfortable truth I learned doing it: most startups do not get owned by some genius with a zero-day. They get owned by boring stuff. A missing check. A key in a public repo. An endpoint nobody rate limited.

So forget the hacker-in-a-hoodie image. You can close the loud 80% of your risk in a single weekend. Here is exactly how I would spend it, in order.

Saturday morning: lock the front door

Start with transport and identity, because that is what everyone touches first.

HTTPS everywhere. No exceptions, no "it is just the staging box." Redirect every HTTP request to HTTPS and turn on HSTS so browsers refuse to downgrade. Free certs from Let's Encrypt mean you have zero excuse in 2026.

Then auth. Do not roll your own. Use a battle-tested library or a provider, and turn on MFA, at least for admin accounts. The number of breaches I have seen that started with one reused admin password is genuinely depressing. Hash passwords with argon2 or bcrypt, never plain text. If you are writing your own crypto, stop and go get a coffee instead.

Saturday afternoon: trust nothing from the client

This is the part that separates real apps from demos.

The browser is not your friend. Anything the client sends can be faked. So every sensitive action has to be re-checked on the server. Can user A edit user B's invoice just by changing an ID in the URL? If you only hid the button in the UI, the answer is yes, and that is a real problem.

Server-side authorization on every endpoint. Validate and sanitize every input. Use parameterized queries so a name like O'Brien does not break your database, or worse. Treat user input as hostile until proven otherwise, because sometimes it genuinely is.

Sunday morning: stop the abuse

Now the loud attacks: brute force, scraping, spam.

Rate limit your auth routes first. A login endpoint that accepts unlimited attempts is a gift to anyone holding a password list. Add sane limits per IP and per account. Put your CDN or a WAF in front if you can. Drop a captcha on signup if bots are already hammering you.

And secrets. Get your API keys, database URLs and tokens out of the client bundle and out of git. They belong in environment variables or a secret manager, full stop. Rotate anything that ever touched a screenshot or a Slack message.

Sunday afternoon: assume you will fail

You will get something wrong eventually. Mature teams plan for that instead of pretending otherwise.

Backups, automated and tested. A backup you have never restored is a rumor, not a backup. Logging that captures who did what and when, so when something looks off you can actually see it. Alerts on the scary events: failed logins spiking, a sudden burst of 500s, an admin action firing at 3am.

None of this is glamorous. All of it works.

Here is the mindset shift that matters more than any single line on the list. Stop asking "am I hackable?" and start asking "when someone tries, what stops them, and how fast will I know?" That second question is what security actually is.

Do the weekend. Your future self, reading an incident report that never had to be written, will thank you.

The $700 Million Patch Equifax Never Applied

Ksatria Bintang Samudra — Sun, 11 Oct 2026 02:30:00 +0000

One unpatched web server. That is the entire story. Everything after it is just the body count.

In March 2017, the Apache Struts project disclosed a critical vulnerability, CVE-2017-5638, and shipped a fix in the same window. It was free. It was public. It came with a clear advisory. One of Equifax's web applications, a consumer dispute portal, was running a vulnerable version of Struts. The patch existed and sat there. Nobody applied it where it counted. By mid-May, attackers were already inside. They roamed for roughly 76 days before anyone at the company noticed.

When it was over, around 147 million people had their names, Social Security numbers, birth dates, and addresses exposed. The eventual settlement climbed to at least 700 million dollars. All of it traces back to a patch that someone left on the shelf.

One known CVE is usually all it takes

I come from penetration testing, so let me be blunt. When I scanned a target, I was not dreaming about some elegant zero-day. I was hoping to find exactly this. An outdated framework. A public CVE with a writeup and a proof of concept. A server somebody forgot to update. That is the actual bread and butter of real intrusions, not the hoodie-in-the-dark movie version.

CVE-2017-5638 was not exotic. It was in every scanner within days of disclosure. So here is the uncomfortable part. Equifax was not taken down by wizards. They were taken down by patience and an off-the-shelf scanner pointed at a box that should have been fixed months earlier. The attackers did not outsmart anyone. They just showed up on time.

The detail that still bothers me

Here is the piece most summaries skip. Equifax actually owned a device that inspected encrypted traffic, exactly the kind of tool that could have spotted the data leaving the building. But the certificate on that inspection device had expired. For something like nineteen months, it was effectively blind. When engineers finally renewed the certificate, the alerts fired almost immediately, and that is how the breach was discovered in the first place.

Sit with that for a second. The alarm was installed. The wiring was done. The battery was just dead, and no one checked for over a year. Your security tooling is not decoration you buy once and forget. A control you do not actively monitor is a control you do not actually have.

So why does this keep happening?

Patching is boring. That is the honest answer. It ships no feature. It wins no demo. It is a grey Tuesday chore that competes against a hundred louder priorities, and it loses that fight, right up until the single time it does not.

But boring and unimportant are not the same word. The gap between a CVE going public and an attacker weaponizing it is now measured in days, sometimes hours. Your asset inventory, the real list of what you run and which exact version, is itself a security control. If your team cannot answer "where do we run Struts, and which build" in five minutes, you have already lost the race before it started.

What I carry into every engagement

So here is what I actually do, and what I would tell any team that will listen. Know your inventory down to the dependency version. Automate your patching so that one tired human forgetting on a Friday is not a single point of failure. And then test that your alarms genuinely fire, because an expired certificate on a blind monitor is somehow more tragic than never having bought the monitor at all.

Equifax did not fall to a nation-state masterstroke. They fell to a to-do item. One line on somebody's backlog, quietly deprioritized, compounding into a 700 million dollar lesson for the rest of the industry.

The scariest exploits are almost never the clever ones. They are the ones you were already warned about, in writing, and decided to handle later.