Blockchain Security Pitfalls: Authentication, Secrets, Supply Chain, and Safe Defaults

[0:00]Herbert: Welcome back to The Blockchain Stack, the show where we dig into the engineering realities—good, bad, and ugly—of building decentralized applications. I’m your host, Jamie, and today we’re exploring the hidden security pitfalls that trip up even the most experienced blockchain teams.

[0:18]Herbert: We’re talking authentication, secret management, supply chain vulnerabilities, and those sneaky unsafe defaults that can leave your app wide open. If you’ve ever wondered why a blockchain app can still get hacked—despite all the cryptography—this episode’s for you.

[1:35]Herbert: Joining me is Maya R. Choudhury, Lead Blockchain Security Engineer at CipherWorks Labs. Maya, welcome to the show!

[1:43]Maya R. Choudhury: Thanks, Jamie. It’s great to be here. Honestly, I’m excited because these topics are close to my heart. I see the same mistakes repeat across projects, from tiny NFT dApps to major DeFi protocols.

[2:07]Herbert: Perfect. Before we dive into the gory details, can you share a bit about your background and what you do at CipherWorks Labs?

[2:20]Maya R. Choudhury: Sure. My team works with blockchain startups and enterprises on securing their architecture—everything from smart contracts and backend APIs to infrastructure and key management. I’ve come from a traditional appsec background, but these days it’s all about web3 and the unique security puzzles it brings.

[3:05]Herbert: Let’s start there. What makes blockchain app security so different from classic web or mobile apps?

[3:20]Maya R. Choudhury: The biggest thing is that there’s no central authority to fix things once they go wrong. In traditional apps, you can reset a password or roll back a database. In blockchain, the code and data are often immutable—mistakes are permanent and public.

[3:38]Herbert: So a bug isn’t just embarrassing—it could mean losing real funds or, worse, irreversibly leaking sensitive information.

[3:49]Maya R. Choudhury: Exactly. Plus, the attack surface is broader: you’ve got user wallets, on-chain logic, off-chain services, and a whole ecosystem of libraries and nodes. Each layer brings its own pitfalls.

[5:30]Herbert: Let’s kick off with authentication. In decentralized apps—dApps—what’s the baseline approach, and where do teams get tripped up?

[5:48]Maya R. Choudhury: Most dApps don’t have traditional logins. Instead, users connect their wallets—like MetaMask or Ledger—and sign a message to prove ownership. But here’s the catch: many teams assume this is always secure, and that’s not true.

[6:05]Herbert: Why not? Isn’t cryptographic signing pretty bulletproof?

[6:15]Maya R. Choudhury: The cryptography is solid, but the implementation often isn’t. For example, if you don’t validate the signed message properly, an attacker could replay an old signature or manipulate the content. Some dApps don’t even bind the message to the specific session or endpoint, so a signature can be reused for something malicious.

[6:47]Herbert: So you’re saying a user could sign a message for one action, and an attacker could replay it for a different action?

[7:00]Maya R. Choudhury: Exactly. Or even for the same action at a later time, in a way the user never intended. Without proper nonce handling or context binding, it’s easy to get caught out.

[7:13]Herbert: What’s a concrete example of how this bites teams in production?

[7:23]Maya R. Choudhury: One project we audited allowed users to sign a generic message to log in, but never rotated the nonce. Attackers who intercepted these could replay the signature and hijack sessions days later. The users thought they were safe, but their wallets were exposed.

[8:20]Herbert: Oof. Let’s talk about wallet integrations. I know this is where a lot of teams try to simplify onboarding, but what can go wrong?

[8:34]Maya R. Choudhury: The classic mistake is assuming the wallet provider handles all security. In reality, a dApp needs to check the wallet’s origin, verify the signature, and handle disconnects or revocations. I’ve seen dApps continue to trust a wallet connection long after the user switched accounts or revoked permissions.

[10:45]Herbert: Let’s do a mini case study. Can you walk us through an anonymized wallet integration gone wrong?

[11:00]Maya R. Choudhury: Absolutely. There was a DeFi dashboard that let users connect their wallet and view balances. But the frontend never re-checked the connected account after a user switched in MetaMask. An attacker, with physical or remote access, could switch the account and execute actions as someone else without the app noticing. That led to unauthorized transactions until the bug was caught.

[12:05]Herbert: So the dApp trusted the initial connection, but didn’t verify changes. That’s subtle but devastating.

[12:15]Maya R. Choudhury: Right. Always listen for account change events and re-authenticate if the wallet context changes.

[13:20]Herbert: Let’s pause and define ‘secrets’ in the blockchain world. We’re not just talking about API keys, right?

[13:35]Maya R. Choudhury: Correct. ‘Secrets’ include private keys, seed phrases, API tokens, encryption keys—basically anything that, if leaked, gives someone unauthorized access or control. In blockchain, secrets are often the literal keys to the kingdom.

[15:00]Herbert: How do teams handle secrets in practice? What’s the reality versus the ideal?

[15:20]Maya R. Choudhury: Ideally, secrets are stored in secure vaults or hardware modules, never checked into code, and rotated regularly. But in reality, I still see private keys in environment variables, config files, even hardcoded in scripts that get pushed to public repos.

[15:45]Herbert: Wait, people are still hardcoding private keys in code that goes to GitHub?

[15:55]Maya R. Choudhury: Unfortunately, yes. Sometimes it’s a test key for a demo, but those get reused in production or forgotten about. Attackers scan public repos for these secrets constantly.

[17:10]Herbert: Let’s talk about what happens when secrets leak. Can you walk us through an actual incident?

[17:25]Maya R. Choudhury: Sure. One project leaked an API key with write access to their backend. An attacker found it and started draining funds by issuing withdrawal requests. The team only noticed after users complained about missing balances. It took hours to rotate the keys and secure the endpoints—by then, the damage was done.

[19:45]Herbert: That’s brutal. What’s your process for helping teams avoid this?

[20:00]Maya R. Choudhury: First, we audit all code and CI/CD pipelines for secrets. Then we help teams migrate to secret managers—cloud vaults, HSMs, or dedicated secret storage services. We also set up automated scans that flag accidental leaks before code is merged.

[20:30]Herbert: How about rotating secrets? Is that as painful as it sounds?

[20:45]Maya R. Choudhury: It can be, but it’s essential. For example, set up scheduled rotations, and make sure apps fetch secrets dynamically rather than baking them in at deploy time. That way, a rotated key takes effect instantly.

[22:00]Herbert: Let’s shift gears to supply chain vulnerabilities. For folks new to the term, what does ‘supply chain’ mean in blockchain apps?

[22:17]Maya R. Choudhury: It’s all the code you depend on but didn’t write—open source libraries, node software, smart contract frameworks, even container images. If any one of those is compromised, your whole app could be at risk.

[23:45]Herbert: Got it. Can you share a real example of a supply chain attack in the blockchain world?

[24:05]Maya R. Choudhury: Absolutely. There was a DeFi protocol depending on a popular npm library. That library was hijacked with a malicious update that exfiltrated environment variables—including private keys—whenever their CI/CD pipeline ran. The attacker got access to several production wallets before the community flagged the update.

[25:15]Herbert: That’s a nightmare scenario. But open source is the backbone of blockchain—how do you square that risk?

[25:30]Maya R. Choudhury: I agree it’s a double-edged sword. Open source accelerates innovation, but you can’t blindly trust every dependency. You need to vet maintainers, pin versions, and use integrity hashes. But I know some developers feel this is too strict and slows them down.

[25:54]Herbert: So let’s dig into that. Isn’t excessive caution going to kill developer velocity? Where’s the balance?

[26:10]Maya R. Choudhury: That’s fair—if you lock everything down too much, you lose agility. But I’d argue some basic hygiene, like dependency scanning and approval workflows, pays off. Maybe you don’t need to self-host every library, but you should know what’s in your bundle.

[27:30]Herbert: That makes sense. Maybe it’s not about zero trust, but about thoughtful trust. Shall we recap what we’ve covered so far before heading into unsafe defaults?

[27:40]Maya R. Choudhury: Great idea. So far, we’ve unpacked why authentication isn’t as simple as it seems in dApps, why secret management is a make-or-break concern, and how dependencies can undermine even the best code. Next up: the silent killer—unsafe defaults.

[27:30]Herbert: Alright, welcome back! We’ve covered a lot already—authorization, secrets management, and some of the supply chain risks. But I want to dig a little deeper, especially into how some of these pitfalls show up in production. Can you walk us through a real-world example where a small oversight led to a big headache?

[28:05]Maya R. Choudhury: Absolutely. One that comes to mind is a DeFi app I worked with—of course, anonymized. They were using a pretty common authentication library, hadn’t pinned dependencies, and, well, a patch release upstream introduced a subtle breaking change. Their session tokens suddenly became predictable under certain conditions. It wasn’t picked up in testing, but attackers found it in the wild. Funds were drained before they caught it.

[28:37]Herbert: Ouch. So, a supply chain issue, but also a failure to test for safe defaults?

[28:50]Maya R. Choudhury: Exactly. The library's default token generator wasn’t cryptographically strong enough, but nobody noticed because their test cases were too shallow—they only checked for uniqueness, not unpredictability.

[29:10]Herbert: It’s amazing how often teams assume ‘defaults’ are safe. What other defaults have you seen bite blockchain teams?

[29:34]Maya R. Choudhury: One biggie is access control. Some frameworks ship with permissive admin APIs. If you don’t explicitly lock them down or disable them, you might expose dangerous methods. We’ve seen projects accidentally let anyone call mint or burn functions, just because the default config was ‘open’ in dev and nobody toggled it for prod.

[29:50]Herbert: That sounds like a nightmare. How do you recommend teams catch these before they go live?

[30:10]Maya R. Choudhury: It starts with having a deployment checklist—literally a document that says, ‘Are all admin APIs disabled? Are only the necessary ports open? Are secrets rotated?’ And, crucially, a peer review step that’s not just code but your configuration and infrastructure as well.

[30:38]Herbert: You mentioned secrets rotation—what’s the practical way to do that in blockchain apps? Especially with wallets and private keys?

[31:05]Maya R. Choudhury: Great question. For server-side secrets, using a managed secrets store—something like HashiCorp Vault or a cloud KMS—is best. For end-user wallets, you can’t rotate their private keys, but you can encourage regular key changes, make seed phrase backups easier, and even alert users if their keys have been exposed in a breach.

[31:25]Herbert: Can you share a quick story about a secrets management fail?

[31:45]Maya R. Choudhury: Sure. There was a project where the deployment pipeline dumped environment variables—containing private keys—into build logs. Those logs were public by default. It took a few days before anyone noticed, but by then, the keys had been scraped and used to drain crypto from their hot wallet.

[32:10]Herbert: That’s brutal. Are there automated tools to help catch things like that?

[32:28]Maya R. Choudhury: Yes, there are scanners that look for secrets in your code, logs, and even container images. Tools like TruffleHog and GitGuardian. But you still need process discipline—like making sure logs are private and secrets never enter them in the first place.

[32:47]Herbert: Let’s pivot to supply chain for a second. What are the top two mistakes you see there?

[33:01]Maya R. Choudhury: First, not pinning dependencies—letting ‘latest’ versions float in your package manager. Second, using libraries with no maintenance or tiny teams, which makes them easy targets for takeover attacks.

[33:18]Herbert: Can you walk us through a supply chain attack scenario in the blockchain world?

[33:34]Maya R. Choudhury: Sure. There was a popular Ethereum library that got compromised when the maintainer’s credentials were phished. The attacker published a malicious version that logged wallet seeds to a server. Several projects upgraded automatically and leaked users’ private keys by accident.

[33:56]Herbert: Wow. That’s a perfect storm. What’s your advice—besides pinning versions?

[34:13]Maya R. Choudhury: Vet your dependencies. Look for active maintenance, code audits, and a real community. And consider using allow-lists for dependencies, so nothing gets added without review.

[34:30]Herbert: Alright, let’s switch gears for a rapid-fire round! Ready?

[34:32]Maya R. Choudhury: Let’s do it.

[34:35]Herbert: First up: best way to store a blockchain app’s secrets in production?

[34:38]Maya R. Choudhury: Use a managed secrets store—never hardcode them.

[34:41]Herbert: Most overlooked security setting in a smart contract?

[34:43]Maya R. Choudhury: Function visibility—people forget to restrict to ‘onlyOwner’ or similar.

[34:46]Herbert: One thing every blockchain team should do before launch?

[34:48]Maya R. Choudhury: Run a full third-party audit—no exceptions.

[34:50]Herbert: What’s a red flag in a dependency?

[34:52]Maya R. Choudhury: No recent commits or a single maintainer—that’s risky.

[34:54]Herbert: Are open-source smart contracts always safer?

[34:57]Maya R. Choudhury: Not always. Transparency helps, but only if someone actually reviews them.

[35:00]Herbert: Biggest myth about blockchain security?

[35:03]Maya R. Choudhury: That ‘code is law’—code has bugs, and bugs have consequences.

[35:15]Herbert: Perfect. Alright, let’s zoom back out. I want to touch on people and process. How much of these security failures are technical, and how much are organizational?

[35:34]Maya R. Choudhury: Honestly, it’s a mix. Technical problems are usually symptoms of missed process. If there isn’t a culture of review and accountability, someone will eventually make a mistake—like pushing a sensitive config or skipping a test.

[35:50]Herbert: That resonates. Have you seen any teams turn things around after a breach?

[36:06]Maya R. Choudhury: Definitely. One DAO I worked with had a small exploit—nothing catastrophic, but enough to shake them up. They brought in an external security lead, established incident response playbooks, and started running tabletop exercises. It made a huge difference. Their code reviews now catch issues early.

[36:30]Herbert: That’s encouraging! Let’s do another case study. Can you share one more anonymized story about safe defaults gone wrong?

[36:50]Maya R. Choudhury: Sure. A team used a new framework for their NFT marketplace. They left a ‘demo mode’ flag enabled, thinking it was harmless. In reality, it let anyone impersonate users for ‘testing’ purposes. Within a week of launch, attackers minted thousands of unauthorized NFTs. The team had to halt the whole platform, burn the rogue tokens, and do a forced migration.

[37:15]Herbert: That’s a tough lesson. So, what’s your take on balancing fast iteration versus security? Especially in early-stage blockchain startups.

[37:36]Maya R. Choudhury: My advice is: build quick, but launch slow. Rapid prototyping is fine, but before you touch real funds or user data, pause for reviews, audits, and threat modeling. Shortcuts are okay in the sandbox, but not in production.

[37:55]Herbert: Love that. Let’s talk about testnets and mainnets. Are there common mistakes when teams move from testnet to mainnet?

[38:12]Maya R. Choudhury: Definitely. Teams sometimes forget to update API keys or secrets—they use test credentials in prod. Or, they leave debug endpoints open. And, permissions that made sense in testnet—like giving a dev wallet admin rights—should never carry over to mainnet.

[38:32]Herbert: Are there tools to help automate those environment checks?

[38:47]Maya R. Choudhury: Some CI/CD platforms let you define environment-specific checks. And you can write custom scripts to fail deployments if certain flags or credentials aren’t set correctly. But again, human review is key.

[39:05]Herbert: Switching gears again—what about social engineering? Do you see phishing as a big risk for blockchain teams?

[39:23]Maya R. Choudhury: Absolutely. With so much value in blockchain apps, attackers constantly target team members. We’ve seen phishing for wallet seeds, fake customer support messages, even deepfake video calls trying to trick admins into sharing access.

[39:39]Herbert: How can teams defend against that?

[39:54]Maya R. Choudhury: Security awareness training helps a lot. And use hardware security keys for admin accounts—it makes phishing much harder. Also, strict separation of duties: don’t let any one person have all the keys to the kingdom.

[40:14]Herbert: Let’s talk about monitoring. How do you recommend monitoring smart contracts for suspicious activity?

[40:30]Maya R. Choudhury: Set up on-chain monitors to alert on unusual patterns—like sudden spikes in transactions, or unexpected contract calls. There are services that watch for this, or you can build custom alerts. Also, monitor your own backend for failed logins or odd access patterns.

[40:52]Herbert: Can you give an example where monitoring caught something before it became a disaster?

[41:08]Maya R. Choudhury: Yes—a DEX I worked with set up real-time alerts for large withdrawals. One day, a bot started draining funds at the max rate allowed by the contract. The team paused the contract within minutes, limiting the loss. Without that alert, it would have been much worse.

[41:29]Herbert: That’s a great save. For teams without big budgets, what’s the minimum viable security setup?

[41:44]Maya R. Choudhury: At minimum: strong code review, secrets scanning, dependency pinning, and basic monitoring. You don’t need fancy tools—just discipline and a checklist.

[42:02]Herbert: Let’s drill into threat modeling. How should blockchain teams actually run a threat modeling session?

[42:23]Maya R. Choudhury: Bring the whole team together—devs, ops, even support. Map out every way an attacker might try to access funds or data. Ask, ‘What if this key leaks? What if someone calls this API with a forged token?’ Then document mitigations for each risk.

[42:40]Herbert: Do you recommend any frameworks?

[42:51]Maya R. Choudhury: STRIDE is a classic, but even a simple checklist works. The key is to make threat modeling a regular habit, not a one-off task.

[43:06]Herbert: Let’s talk about incident response. What’s unique about responding to blockchain security incidents?

[43:23]Maya R. Choudhury: Speed is everything. Once funds move on-chain, it’s usually irreversible. So, have pre-written comms, know who to call for pausing contracts, and be ready to coordinate with exchanges to freeze stolen assets if possible.

[43:44]Herbert: Do you think bug bounties are worth it for blockchain projects?

[43:57]Maya R. Choudhury: Yes, if you can afford it. Bounties attract white-hat hackers who might spot issues before criminals do. But they’re not a substitute for audits.

[44:13]Herbert: Have you seen a bounty program actually prevent a hack?

[44:25]Maya R. Choudhury: Absolutely. I’ve seen vulnerabilities that would have led to multi-million dollar losses get reported and fixed thanks to bounty programs. It’s a win-win.

[44:43]Herbert: Let’s spend a few minutes on user education. What should blockchain apps teach their users about security?

[44:59]Maya R. Choudhury: At minimum: never share private keys or seed phrases, use hardware wallets for big funds, and double-check URLs before connecting wallets. Also, warn about common scams and show how to verify real support channels.

[45:15]Herbert: Do you see many teams doing that well?

[45:24]Maya R. Choudhury: Not enough! The best teams bake security tips into onboarding, pop-ups, and docs. But too many hide it in the fine print.

[45:36]Herbert: Are there easy design wins here?

[45:48]Maya R. Choudhury: Yes—make warnings clear but not scary, use icons, tooltips, and short videos. And always make recovery instructions easy to find.

[46:03]Herbert: Alright, we’re heading toward the end. Can we walk through an implementation checklist for blockchain app security? What are your non-negotiables?

[46:10]Maya R. Choudhury: Definitely. Here’s my go-to checklist:

[46:15]Maya R. Choudhury: First, lock down all smart contract permissions. Double-check function visibility—no public or external for admin actions.

[46:21]Maya R. Choudhury: Second, pin all dependencies in your package manager. No ‘latest’ or wildcard versions.

[46:28]Maya R. Choudhury: Third, scan for secrets in code, configs, and build logs. Use tools, but also manual review.

[46:34]Maya R. Choudhury: Fourth, configure a managed secrets store—never hardcode secrets.

[46:39]Maya R. Choudhury: Fifth, enable logging and monitoring for both blockchain and backend events.

[46:45]Maya R. Choudhury: Sixth, run threat modeling and have a peer review for both code and configs before launch.

[46:50]Maya R. Choudhury: Seventh, schedule a third-party audit, and don’t be afraid to delay launch until it’s done.

[46:56]Maya R. Choudhury: Finally, have an incident response plan. Know who handles what if something goes wrong.

[47:05]Herbert: That’s gold. Let’s give listeners a moment to jot those down.

[47:12]Maya R. Choudhury: And seriously—don’t skip any! Every item there has been missed by real teams… with real consequences.

[47:19]Herbert: Before we wrap, any final advice for teams building in this space?

[47:30]Maya R. Choudhury: Stay humble. Even the best teams miss things. Build a habit of review, ask for outside opinions, and keep learning. And remember, security is never ‘done’—it’s ongoing.

[47:42]Herbert: Last quick question: what’s the most underrated skill for blockchain security engineers?

[47:48]Maya R. Choudhury: Empathy. Being able to think like users—and like attackers—makes all the difference.

[47:54]Herbert: Love that. Any good resources to recommend for folks looking to go deeper?

[48:06]Maya R. Choudhury: Check out open-source smart contract audits, OWASP’s blockchain security guides, and follow security researchers on social media. There’s a lot to learn from public post-mortems.

[48:22]Herbert: Alright, let’s wrap up with a lightning recap. Here’s what we covered: authentication mistakes, secrets management, supply chain attacks, safe defaults, monitoring, and even people-process trade-offs.

[48:34]Maya R. Choudhury: And don’t forget the real-world case studies—always more to learn from failures than successes.

[48:40]Herbert: True. If you had to leave listeners with one last takeaway, what would it be?

[48:48]Maya R. Choudhury: Security is everyone’s job. Don’t leave it for ‘just the security person’—make it part of your team’s DNA.

[48:56]Herbert: Perfect. Well, thank you so much for joining us and sharing all these hard-won lessons.

[49:01]Maya R. Choudhury: My pleasure. Thanks for having me.

[49:07]Herbert: Before we go, let’s run through a final practical checklist for listeners. If you’re building or maintaining a blockchain app, here’s what to do:

[49:23]Herbert: 1. Lock down smart contract permissions. 2. Pin all dependencies. 3. Scan for secrets leaks. 4. Use a managed secrets store. 5. Monitor both on-chain and backend events. 6. Run threat modeling. 7. Schedule a third-party audit. 8. Prepare an incident response plan.

[49:44]Herbert: Did I miss anything crucial?

[49:52]Maya R. Choudhury: That’s a strong list. Maybe just add: keep educating your users and your team—security is a journey, not a destination.

[50:02]Herbert: Awesome. For folks who want to connect or learn more, where can they find you?

[50:10]Maya R. Choudhury: I’m active on most developer forums and social media under my handle. Happy to answer questions or share more resources.

[50:15]Herbert: We’ll link to those in the show notes. Thanks again for being here.

[50:20]Maya R. Choudhury: Thanks so much!

[50:31]Herbert: And to our listeners—thanks for tuning in to this episode of Softaims. We hope you’re walking away smarter and safer.

[50:43]Herbert: If you enjoyed the episode, please subscribe, leave a review, and share it with your team. Security is better together.

[50:52]Herbert: Until next time, build responsibly and stay secure.

[51:00]Maya R. Choudhury: Take care, everyone!

[51:15]Herbert: Alright, we’re at the finish line. Thanks for joining us for this deep dive into security pitfalls in blockchain apps. We’ll be back soon with more conversations from the edge of technology.

[51:27]Herbert: Signing off from the Softaims team. Stay curious. Stay safe.

[51:32]Maya R. Choudhury: Bye everyone!

[55:00]Herbert: And that’s a wrap. Thanks for listening.