DEV Community: Kokal Limited

4.9M Charter Customers Exposed: What Developers Need to Know About the ShinyHunters Breach

Kokal Limited — Fri, 25 Sep 2026 05:18:38 +0000

ShinyHunters just dumped personal data on 4.9 million Charter Communications (Spectrum) customers after the telecom refused to pay ransom. Names, emails, phone numbers, and physical addresses are already circulating on the dark web and being weaponized for phishing.

This happened the same week the group claimed a separate 6-million-record theft from Carnival Corporation. Industrial-scale extortion is the new normal.

What Was Leaked

Have I Been Pwned verified the breach. Confirmed exposed data:

- Full customer names
- Email addresses
- Phone numbers (home + mobile)
- Physical/billing addresses
- ~85,000 internal staff records (including job titles)

Charter disputed the severity, stating "no sensitive PI or CPNI data was exfiltrated." Technically true — but a name + email + phone + address combo is more than enough to run targeted phishing, SIM swapping, or business email compromise (BEC) attacks.

The 42M records ShinyHunters originally claimed vs. the 4.9M confirmed by HIBP? Likely duplicates — multiple records per customer (billing address, service address, contact email) inflating the raw count.

Why Developers Should Care

If you build anything that handles user PII, this breach is a reminder of the attack surface you're responsible for:

Credential stuffing — leaked emails + common passwords = automated account takeovers across your platform
Phishing as a service — verified email/phone combos are sold and reused; your users are targets
BEC via staff directories — the 85K internal records with job titles are a ready-made spear-phishing list

Practical Hardening Checklist

# Check if your users are in the breach
curl "https://haveibeenpwned.com/api/v3/breachedaccount/{email}" \
  -H "hibp-api-key: YOUR_KEY"

For your own systems:

[ ] Enforce unique, strong passwords — integrate HIBP's Pwned Passwords API at signup/login
[ ] Add MFA — TOTP at minimum, passkeys if you can
[ ] Rate-limit and monitor login endpoints for credential stuffing patterns
[ ] Scope your data retention — don't store what you don't need
[ ] Audit what PII columns live in your DB and who can query them

Check If You're Affected

If you're a Charter/Spectrum customer, check haveibeenpwned.com with your account email. Even if you're not in this specific breach, assume your email is in some breach and act accordingly.

The playbook: rotate passwords on any account sharing credentials with your Charter login, enable MFA everywhere, and watch for unusually targeted phishing — attackers with your address and phone number can craft convincing lures.

ShinyHunters isn't slowing down. Two major US corps in one week. Assume your users' data is already out there somewhere.

Originally published on BestPasswordGenerator.org

Bitwarden vs 1Password (2026): Which Password Manager Should Developers Trust?

Kokal Limited — Wed, 23 Sep 2026 05:18:38 +0000

Bitwarden vs 1Password (2026): Which Password Manager Should Developers Trust?

Both Bitwarden and 1Password are zero-knowledge, end-to-end encrypted — meaning your master password never leaves your device and neither vendor can read your vault. But the how differs in ways that matter if you care about threat models.

Cryptographic Foundations

Bitwarden uses AES-256 encryption and lets you choose your KDF:

PBKDF2-SHA256  → configurable iteration count (default: 600,000)
Argon2id       → memory-hard, more resistant to GPU brute-force

1Password layers a Secret Key on top of your master password — a locally-generated 128-bit value that never hits their servers. Your vault encryption key is derived from both:

vault_key = KDF(master_password + secret_key)

This means even a full server breach + leaked master password = attacker still can't decrypt your vault. Strong defense-in-depth. The cost: onboarding a new device requires that Secret Key, so you need to store the rescue kit PDF somewhere safe.

Both support FIDO2/WebAuthn hardware keys (YubiKey, passkeys) for 2FA, which is the right call for any developer managing production credentials.

Open Source vs. Proprietary

This is where the real philosophical split lives.

	Bitwarden	1Password
Source code	Public (auditable)	Closed
Self-hosting	Yes (Vaultwarden or official)	No
Audits	Public + community	SOC 2 + whitepaper
Cloud dependency	Optional	Required

Bitwarden lets you self-host the entire backend. If you're running infra with strict compliance requirements (HIPAA, GDPR, FedRAMP), that's not a nice-to-have — it's often a requirement. Vaultwarden makes this pretty painless:

docker run -d \
  --name vaultwarden \
  -v /vw-data/:/data/ \
  -p 80:80 \
  vaultwarden/server:latest

1Password is cloud-only. Since their v8 rewrite, there's no local vault option — a controversial move among power users who valued offline access.

Which One Should You Pick?

Choose Bitwarden if you value transparency, want to audit the crypto implementation yourself, need self-hosting, or are budget-conscious (free tier is genuinely good).
Choose 1Password if you want the most friction-free team/family UX, trust managed infrastructure, and appreciate the extra layer the Secret Key provides against server-side attacks.

Both are excellent choices that exceed what most developers actually need from a security standpoint. The decision is more about your trust model than raw cryptographic strength.

Originally published on BestPasswordGenerator.org

VS Code Zero-Day: One Click and Your GitHub Token Is Gone

Kokal Limited — Mon, 21 Sep 2026 05:18:32 +0000

A critical zero-day in VS Code's browser-based github.dev editor lets attackers steal your GitHub OAuth token with a single link click. Security researcher Ammar Askar published the exploit on June 2, 2026 — with only one hour's notice to Microsoft — and the code is already public.

How It Works

The attack targets the webview message-passing system, a legitimate VS Code API that extensions use to communicate with embedded web views. Here's the chain:

Attacker crafts a malicious github.dev URL
Victim clicks the link — no prompts, no warnings
The URL injects a fake extension via the webview message channel
The extension reads the active GitHub OAuth token
Token is exfiltrated to an attacker-controlled server

Victim clicks link
       ↓
github.dev loads with weaponized parameter
       ↓
Fake extension injected via webview API
       ↓
OAuth token silently read + sent to attacker

The stolen token gives unrestricted access to every repo the victim can reach — private, public, internal, org repos, and potentially CI/CD credentials too.

Why Full Disclosure?

Askar didn't give Microsoft the usual 90-day window. His reasoning: in 2022 he reported a critical RCE in VS Code's GitHub Repositories extension through the bug bounty program. Microsoft shipped the fix labelled as a "reliability improvement" — no CVE, no researcher credit, no bounty.

His take:

"In my past experience reporting github.dev bugs to them, they tell you that it's out of scope and go report it to MSRC. And as I outlined in the article, I really don't want to deal with MSRC on VSCode bugs."

It's a familiar story in the security community, and it raises legitimate questions about how large vendors handle browser-based product vulnerabilities versus core product bugs.

What You Should Do Right Now

No patch exists yet. Protect yourself manually:

# 1. Revoke all existing GitHub tokens
# GitHub → Settings → Developer settings → Personal access tokens → Revoke all

# 2. If you use the GitHub CLI, re-authenticate
gh auth logout
gh auth login

# 3. Review recent token activity
gh api /user/installations

Also:

Clear github.dev browser cookies and site data
Re-create tokens with minimum required scopes only
Enable hardware-based 2FA (FIDO2/WebAuthn — not SMS)
Check your GitHub audit log at github.com/settings/security-log

The Bigger Picture

This is a good reminder that a strong password alone doesn't protect you against OAuth token theft — the attacker never touches your password at all. Token hygiene (short-lived tokens, minimal scopes, regular rotation) matters as much as credential strength.

The median time from public disclosure to active exploitation has dropped to 12 hours in 2026, according to CISA's KEV catalog. If you use github.dev regularly, treat this as urgent.

Originally published on Best Password Generator

Browser vs Dedicated Password Manager in 2026 — Which Is Actually Safer?

Kokal Limited — Thu, 17 Sep 2026 05:18:43 +0000

Most developers I know fall into one of two camps: either they're running a dedicated password manager with a carefully curated vault, or they're letting Chrome/Safari/Edge handle everything "because it's good enough." Let's talk about why that second choice has some real structural problems.

What Browser Managers Do Well

Built-in managers (Chrome, Edge, Safari) have genuinely improved. They:

Auto-save and autofill credentials
Sync across devices via your Google/Microsoft/Apple account
Flag passwords caught in known data breaches
Support passkeys (Safari/iCloud Keychain especially)

For low-stakes personal use, that's not nothing. Zero setup, zero cost, works invisibly.

Where They Fall Apart

The moment you leave the parent ecosystem, things break. Safari passwords are awkward in Chrome on Windows. Edge credentials don't follow you cleanly to iOS. And entire feature categories are just missing:

No secure sharing — you're back to texting passwords to teammates
No secure notes — nowhere to store SSH keys, API tokens, or software licenses alongside logins
No bulk health auditing — beyond a basic breach alert, there's no vault-wide weak/reused password scan
No emergency access — no mechanism to grant a trusted contact access if needed

The Security Problem Is Structural

This is the part that matters most. Browser managers protect your vault using your device login or browser account — not a separate master password. Anyone who can unlock your computer can often view saved passwords in plain text with a few clicks.

Worse, infostealer malware specifically targets browser-saved passwords because they're easy to extract. This isn't theoretical — it's an active attack vector.

Dedicated managers like Bitwarden, 1Password, and NordPass are built around zero-knowledge, end-to-end encryption:

User master password
        ↓
  Key derivation (PBKDF2 / Argon2)
        ↓
  Local encryption/decryption
        ↓
  Encrypted blob → synced to server
  (provider never sees plaintext)

Even if the provider's servers are breached, attackers get unreadable ciphertext. The provider has no recovery path because they genuinely can't decrypt your vault.

Quick Comparison

Feature	Browser Manager	Dedicated Manager
Encryption model	Device/account-tied	Zero-knowledge, E2EE
Cross-platform	Ecosystem-locked	Full parity
Secure sharing	❌	✅
Secure notes	❌	✅
Vault health audit	Basic	Comprehensive
Emergency access	❌	✅

The Bottom Line

If your threat model is "I keep reusing the same password everywhere," a browser manager is still an upgrade. But if you're a developer managing staging credentials, API keys, shared team logins, or anything sensitive — the architectural difference of a dedicated tool with a separate master key is worth the small overhead.

Bitwarden has a solid free tier and is open source if you want to self-audit the implementation.

Originally published on bestpasswordgenerator.org

Security Key vs Authenticator App (2026) — Which MFA Method Actually Protects You?

Kokal Limited — Tue, 15 Sep 2026 05:19:01 +0000

Most developers have MFA enabled on their accounts. Far fewer have thought carefully about which MFA method they're using — and the gap between them matters more than you might think.

How They Work Under the Hood

Authenticator apps (Google Authenticator, Authy, etc.) use TOTP — a 6-digit code derived from a shared secret and the current timestamp:

TOTP = HMAC-SHA1(secret, floor(unix_time / 30))

The code refreshes every 30 seconds. Both your app and the server independently compute the same value — no network call needed.

Hardware security keys (YubiKey, etc.) use FIDO2/WebAuthn — public-key cryptography with a challenge-response flow:

1. Server sends a random challenge + the registered domain
2. Key signs the challenge with its private key (never leaves the device)
3. Server verifies with the stored public key

The domain is baked into step 1. That's the critical difference.

The Phishing Problem

TOTP codes can be phished. A convincing fake login page can capture your code and replay it within the 30-second window — this is exactly how modern AiTM (adversary-in-the-middle) phishing kits work.

FIDO2 keys are phishing-resistant by design. The key refuses to sign challenges from domains it wasn't registered with. A pixel-perfect phishing clone of GitHub simply cannot complete the handshake.

This isn't theoretical. Google deployed hardware keys to 85,000+ employees and reported zero successful phishing-based account takeovers afterward.

2026 MFA Ranking (Weakest → Strongest)

Method	Phishing Resistant	Practical
SMS OTP	❌	✅
TOTP (Authenticator App)	❌	✅
Push approval	❌	✅
Hardware Security Key (FIDO2)	✅	⚠️
Passkeys	✅	✅

When to Use Each

Use a hardware key for your most critical accounts: GitHub, AWS, Google Workspace, your password manager, anything with production access. A $25–$50 YubiKey is cheap insurance against credential theft.

Use an authenticator app for everything else — the long tail of accounts where budget or device compatibility rules out a key. TOTP still blocks the vast majority of automated attacks.

A few quick wins if you're sticking with TOTP:

Store backup codes in your password manager or print them — not in your camera roll
Use an app with encrypted cloud backup (Authy, 1Password's built-in TOTP) so a lost phone doesn't lock you out
Never manually type a code into a URL you didn't navigate to yourself

The Takeaway

Use a hardware key for anything that would hurt if compromised. Use TOTP for the rest. Avoid SMS wherever you have the choice. And if a service only offers SMS 2FA in 2026 — that's a signal about how seriously they take security.

Originally published on bestpasswordgenerator.org

Can a Password Manager Prevent Identity Theft? (2026 Data Says Yes)

Kokal Limited — Sun, 13 Sep 2026 05:18:49 +0000

Most developers know they should use unique passwords everywhere. But here's the harder question: does a password manager actually prevent identity theft, or just make it more convenient to get hacked?

The 2026 data is clear. IBM's Cost of a Data Breach report found 49% of breaches involved compromised credentials, and Verizon's DBIR confirms credential theft is the #1 vector for identity fraud. A password manager directly addresses the root cause.

How the Attack Chain Works

Identity theft in 2026 rarely starts with a stolen SSN. It starts with a single reused password:

Credential harvesting — phishing, breach, or stuffing attack captures one login (usually email or social)
Credential stuffing — that email/password combo gets tried against banking, tax portals, healthcare, investment accounts (Akamai reports 15 billion stuffing attempts/month)
Account takeover — attacker pivots via "forgot password" flows once inside your email
Identity exploitation — fraudulent tax returns, new credit lines, redirected direct deposits

The fix is boring but effective: break the chain at step one.

What a Password Manager Actually Does

Account: bank.com      → j4#Kp9!mXqL2@vNrT8Yw
Account: gmail.com     → Zn7&Qs3RdWe5*HbM1cPx
Account: github.com    → Lk8$Vt2FuAj6^YnC4mEo

Each credential is unique, 20+ characters, generated via CSPRNG — the same randomness class used in TLS. One breached service gives an attacker exactly one useless credential.

Beyond generation, modern managers layer on:

Dark web monitoring — alerts when your email appears in breach dumps (Dashlane, 1Password, Keeper)
Breach history checks — flags existing weak/reused passwords on setup
Phishing resistance — autofill only triggers on the exact registered domain, so paypa1.com never gets your password

Where Password Managers Don't Cover You

They don't protect against:

SIM swapping (use an authenticator app, not SMS 2FA)
Social engineering that bypasses the login entirely
Malware with keylogging capabilities
Data brokers holding your PII

The practical stack for 2026:

Layer	Tool
Unique passwords	Password manager
MFA	Hardware key or TOTP app
Credit monitoring	Freeze + alert service
Breach alerts	HaveIBeenPwned / manager built-in

Bottom Line

A password manager won't make you identity-theft-proof. But it eliminates the single most common attack path — credential reuse — and does it automatically. The FBI's IC3 recorded 880,000+ identity theft complaints in 2025 with $12.5B in losses. Most of those started with one reused password.

If you're building auth for your users, this is also an argument for pushing breach-detection APIs and enforcing password uniqueness at the application layer. Your users' credential hygiene is your security surface too.

Originally published on bestpasswordgenerator.org

Google Authenticator vs Duo Mobile 2026 — Which 2FA App Wins?

Kokal Limited — Fri, 11 Sep 2026 05:18:33 +0000