DEV Community: Kokal Limited

How to Change a Password Correctly: A Developer's Guide for Small Teams

Kokal Limited — Fri, 31 Jul 2026 14:38:45 +0000

Changing a password sounds trivial—click "forgot password," type a new one, done. But if you run infrastructure for a small business or team, doing it correctly matters more than doing it fast. A sloppy password rotation can lock out services, break automation, or leave old credentials floating around in logs and config files.

Here's how to do it right.

1. Don't Just Change It—Rotate It

A password change should assume the old one is already compromised. That means:

Invalidate active sessions after the change
Revoke API tokens or app passwords tied to the old credential
Check for the password hardcoded in scripts, .env files, or CI secrets

# Quick sweep for a leaked password string in your repo
grep -rn "OldP@ssw0rd" . --include="*.env" --include="*.yml"

If it shows up anywhere in version control, rotating the password isn't enough—you'll want to scrub the history too.

2. Generate, Don't Invent

Humans are bad at randomness. Let a tool do it:

# 20-char high-entropy password
openssl rand -base64 20

# Or with a password manager CLI
op item create --category=login --generate-password='letters,digits,symbols,32'

Aim for length over complexity. A 20+ character random string beats P@ssw0rd! every time.

3. Update Everywhere It Lives

The most common failure isn't a weak password—it's a stale one. When you rotate a shared credential, update:

The password manager (single source of truth)
CI/CD secrets and environment variables
Any service accounts or cron jobs that authenticate with it

4. Enforce It as Policy

For a small team, tooling beats memory. Push everyone onto a shared password manager, require MFA, and stop forcing arbitrary 90-day resets—NIST guidance now recommends changing passwords only when there's evidence of compromise, not on a fixed timer.

Bottom Line

A correct password change is a small workflow: rotate the assumption of compromise, generate high entropy, propagate everywhere, and back it with MFA. Do that consistently and password hygiene stops being a fire drill.

Originally published on strongpassfactory.com

Building a Password Policy for a Small Dev Team (2026 Edition)

Kokal Limited — Wed, 29 Jul 2026 13:18:51 +0000

You've got five people. Nobody owns "IT." One dev still uses Password1! for the CRM, and someone shared a login with a contractor over email last week. Your whole stack sits behind the weakest credential on the team.

Small teams face enterprise-grade threats on a hobbyist budget. The Verizon 2026 DBIR found that 43% of cyberattacks target small businesses, and stolen credentials are still the top attack vector (53% of breaches). For teams of 10 or fewer, IBM puts the average credential-breach cost at $98,000. A written, followed password policy is the cheapest defense you have.

What the policy actually needs

Here's the 2026 baseline vs. what you should ship:

Requirement	Old minimum	2026 recommendation
Length	8 chars	12+ chars (NIST SP 800-63B)
Complexity	Mixed types	Drop composition rules — favor length
MFA	Optional	Mandatory, all accounts
Expiry	Every 90 days	Only on known compromise
Password manager	Optional	Mandatory, company-wide
Breach checks	None	Auto-check against HIBP
Shared creds	Allowed	Forbidden — use secure sharing

Both NIST and NCSC dropped mandatory periodic rotation. A 15-character passphrase beats a P@ssw0rd! that ends up on a sticky note.

Pick your infrastructure first

Tools before rules. For a small team that means a shared password manager + MFA everywhere.

Password manager: Bitwarden Teams or 1Password Business, ~$3–4/user/month. Shared vaults, secure sharing, breach monitoring. Keeper Business is worth a look if you're under HIPAA/PCI-DSS/ISO 27001.
MFA: Non-negotiable on anything internet-facing. Google/Microsoft Authenticator are free; Duo has a free tier up to 10 users with wide app integration.

Enforce it in code, not vibes

Don't just write "12+ characters" in a wiki — validate it. A quick example:

import re, hashlib, requests

def is_strong(pw: str) -> bool:
    return len(pw) >= 12

def is_pwned(pw: str) -> bool:
    sha = hashlib.sha1(pw.encode()).hexdigest().upper()
    prefix, suffix = sha[:5], sha[5:]
    res = requests.get(f"https://api.pwnedpasswords.com/range/{prefix}")
    return any(line.split(":")[0] == suffix for line in res.text.splitlines())

The HIBP range API uses k-anonymity — you only send the first 5 hash chars, never the password. Wire this into signup and password-reset flows so weak or breached credentials never make it in.

The rules employees actually follow

12+ characters, generated by the manager (nobody memorizes them)
MFA on every account, no exceptions
No shared logins — use the vault's sharing feature
Rotate only on a known breach
Run quarterly audits and a short onboarding walkthrough

A policy is only as good as its enforcement. Automate the checks, make the secure path the easy path, and revisit it every quarter.

Originally published on strongpassfactory.com

What Devs Should Learn From the Dashlane Brute-Force Attack

Kokal Limited — Wed, 29 Jul 2026 13:03:14 +0000

On May 31, 2026, Dashlane got hit with a coordinated brute-force attack that locked thousands of users — including team-plan customers — out of their vaults during work hours. Dashlane confirmed to BleepingComputer that automated controls suspended targeted accounts. No internal systems were breached, and accounts were restored. But if your team depends on a password manager, this is worth a look.

The actual attack vector: credential stuffing

The attack wasn't some exotic zero-day. It was credential stuffing — replaying leaked email/password pairs against a high-value login endpoint. It works because of one stubborn human habit: password reuse.

Attackers pull credential pairs from breach dumps and script them against a target:

# Conceptually, what an attacker's loop looks like
for email, password in leaked_credentials:
    r = session.post("https://vault.example.com/login",
                     data={"email": email, "password": password})
    if r.status_code == 200:
        log_hit(email)  # reused password → account compromised

Per Verizon's 2024 DBIR, 43% of cyberattacks target small businesses, and only 14% are prepared. A locked password manager isn't a minor annoyance — it means no access to shared vaults, client creds, or infra secrets mid-incident.

Defense: what you can actually configure

If you administer a team plan, MFA enforcement is the single highest-leverage control. Credential stuffing dies instantly when a second factor is required:

# The policy posture you want on any team password manager
mfa:
  enforcement: required      # not "optional"
  methods: [totp, webauthn]  # prefer hardware/WebAuthn over SMS
lockout:
  policy: admin-configurable # not vendor-locked
  admin_override: true       # someone can unlock a locked-out director
audit_logging: full

Consumer plans give you vendor-defined lockout and optional MFA. Business tiers (1Password Teams, Keeper Business, LastPass Business) let you mandate MFA, configure lockout, and unlock accounts as an admin.

A short checklist for engineers

Enforce MFA — prefer WebAuthn/TOTP over SMS. This alone neutralizes credential stuffing.
Document recovery — designate a backup admin who can override lockouts. Don't let one locked account halt the team.
Audit reused passwords — run your team through Have I Been Pwned or your manager's built-in breach report.
Rate-limit your own login endpoints — if you ship auth, the same attack applies to you.

The uncomfortable takeaway: even a well-built password manager can be knocked offline by attackers weaponizing your users' reused passwords. MFA and a documented recovery path are what keep a Tuesday-morning attack from becoming a Tuesday-morning outage.

Originally published on StrongPassFactory.

The 10-Minute Offboarding Checklist Every Dev Team Ignores

Kokal Limited — Mon, 27 Jul 2026 13:09:17 +0000

When an employee leaves, how fast can you kill their access? If it's not "under 10 minutes," you have a problem.

In our analysis of SMB security incidents this year, failure to revoke former-employee access was the root cause of 34% of preventable breaches — more than phishing, more than weak passwords. The Verizon 2026 DBIR pegs 28% of breaches on internal actors, and ex-employees with live credentials are a big slice of that.

These failures are quiet and boring. No zero-day, no APT — just a token nobody rotated. Which is exactly why they're so preventable.

Why it breaks in small teams

Enterprises wire HRIS into their IdP, so termination auto-deactivates accounts. Most of us run manual processes that fall apart under pressure:

No account inventory — 20+ SaaS subscriptions and nobody knows who has access to what.
SSO blind spots — you kill the IdP, but they signed up for three tools directly with a personal-looking email, bypassing SSO entirely.
Shared vault chaos — if they owned the team password vault, revoking them can lock everyone out.
API keys and PATs — the scariest one for devs. Personal access tokens keep working long after the human is gone.

The NCSC measures the risk window in hours, not days.

The core checklist

Run these in order, starting the minute notice is given:

# 1. Disable the identity provider account first (Entra ID / Google Workspace / Okta)
# 2. Revoke ALL active sessions — invalidate live tokens, don't just reset the password
gcloud identity ... # or your IdP's "sign out everywhere"

# 3. Rotate the shared vault master + any secrets they could read
# 4. Remove from every SaaS app individually (CRM, billing, PM, email)

# 5. Kill API keys and personal access tokens — check every provider
gh auth status              # audit GitHub PATs
aws iam list-access-keys --user-name former.employee

Passwords are polite; session and token revocation is what actually locks the door. A disabled account with a live OAuth token is still an open door.

Automate what you can. Even a simple runbook — a checklist in your wiki with owners assigned per step — beats scrambling under emotional pressure the day someone gets walked out.

The goal isn't enterprise tooling. It's a repeatable process you can run in 10 minutes, every single time.

Originally published on strongpassfactory.com.

Insider Threat Detection: SMB Password Policies That Actually Work

Kokal Limited — Sat, 25 Jul 2026 13:05:33 +0000

When we think about security threats, we default to the external attacker — ransomware, phishing, brute-force bots. But according to the Verizon 2025 DBIR, insider threats account for 34% of breaches in small and medium businesses. And the top attack vector? Abused or mismanaged passwords.

The good news: you don't need a SOC to defend against this. You need sane password policies and a few controls wired into your credential workflow.

The three kinds of insider

Not every insider is malicious. Knowing the category tells you which control to reach for:

Malicious — departing staff or contractors intentionally misusing access (exfiltrating a customer DB before resignation). IBM pegs the average cost at ~£210k per incident.
Negligent — well-meaning people bypassing policy for convenience: passwords in Slack, credentials in a shared spreadsheet, no logout on shared machines. This is the biggest bucket — 56% of insider incidents.
Compromised — an attacker operating under a real employee's stolen identity. NCSC attributes 72% of detected UK SMB insider incidents to compromised credentials.

Controls that map to real attack patterns

1. Just-in-time (JIT) privileged access. Stop granting permanent admin. Issue elevated credentials that expire on a timer.

# Example: time-boxed elevation policy
grant:
  role: db-admin
  user: alice@company.com
  ttl: 30m          # auto-revoke after 30 minutes
  approval: required
  audit: true

2. Credential check-in / check-out. Shared accounts (vendor portals, social logins, admin consoles) should live in a vault that logs access and blocks concurrent use.

[vault] alice checked OUT vendor-portal @ 14:02
[vault] bob requested vendor-portal → QUEUED (in use)
[vault] alice checked IN vendor-portal  @ 14:19

3. Automated offboarding. Every departure should trigger a revocation workflow — rotate any shared secrets the person touched, kill their sessions, and confirm.

# Offboarding hook (pseudo)
revoke_sessions "$USER"
rotate_shared_secrets --touched-by "$USER"
disable_sso "$USER" && notify_admin "offboarded: $USER"

Why this works

None of these require expensive tooling — most business password managers support JIT and check-in/check-out out of the box. The pattern is the same each time: short-lived credentials, logged access, and automatic revocation. You reduce the blast radius of a malicious insider, remove the shortcuts a negligent one relies on, and shrink the window a compromised account stays useful.

Start with a baseline password policy, layer these three controls on top, and you've covered the vast majority of insider-driven breaches without hiring a security team.

Originally published on strongpassfactory.com

MFA for SMBs in 2026: A Developer's Quick-Start Guide

Kokal Limited — Thu, 23 Jul 2026 13:03:26 +0000

If you build or maintain systems for a small business, multi-factor authentication (MFA) is the single highest-leverage security control you can ship. The Verizon 2026 DBIR found that 81% of breaches involve stolen or weak passwords — and MFA neutralizes most of those attacks even when credentials leak.

Here's the developer's-eye view.

Why it matters

Passwords fail because people reuse them. When a third-party service gets breached, attackers run credential-stuffing against your login endpoint. MFA adds a second factor that makes automated attacks economically pointless. IBM's Cost of a Data Breach 2026 report showed SMBs with MFA on all accounts cut breach costs by 67%.

Pick the right factor

MFA Type	Security	Cost	Best for
SMS codes	Low	Free	Fallback only
TOTP apps	Good	Free	Most SMB accounts
Push notifications	Good	£2-5/user/mo	Simple approval flows
Hardware keys (FIDO2)	High	£25-50 once	Admin & financial access
Passkeys (multi-device FIDO)	Highest	Free	Passwordless future

Skip SMS as a primary factor — NIST SP 800-63B no longer recommends it thanks to SIM-swap attacks (the UK NCSC logged a 340% jump in 2025).

TOTP is the sweet spot

Time-based one-time passwords work offline, cost nothing, and are trivial to integrate. If you're on Node, most of the work is one library:

import { authenticator } from 'otplib';

// Generate a per-user secret at enrollment
const secret = authenticator.generateSecret();

// Build the otpauth:// URI for the QR code
const uri = authenticator.keyuri(user.email, 'YourApp', secret);

// Verify the 6-digit code on login
const isValid = authenticator.verify({ token, secret });

Store secret encrypted at rest, render uri as a QR code (Google Authenticator, Authy, 2FAS all scan it), and gate the session on isValid.

Common pitfalls

No backup codes → users get locked out and disable MFA.
Verifying tokens without a replay window or rate limit.
Storing TOTP secrets in plaintext.
Treating SMS as your primary factor.

For anything privileged — admin panels, payment systems — step up to FIDO2/WebAuthn hardware keys. They're phishing-resistant in a way TOTP isn't.

Ship MFA before you ship the next feature. It's the cheapest security win you'll get all year.

Originally published on strongpassfactory.com

Phishing Prevention for Small Dev Teams: A 2026 Playbook

Kokal Limited — Tue, 21 Jul 2026 13:03:41 +0000

If you build software for a small business, security often lands on your desk by default. And the highest-ROI thing you can ship isn't a fancy WAF — it's phishing prevention. The Verizon 2026 DBIR puts 74% of breaches on the human element, with phishing as the primary infection vector. 43% target small businesses specifically.

Here's why SMBs get hit: attackers follow the path of least resistance. Enterprises run simulated phishing platforms and advanced email filtering. Teams under 50 people usually run none of that. KnowBe4's 2025 report found SMB employees are 3.5x more likely to fall for a phishing email than enterprise counterparts. The average phishing-related breach for companies under 100 employees costs $82,000 (IBM, 2026) — enough to sink a small operation.

The dominant vector is credential theft

Most phishing isn't exotic. It's a convincing login page that harvests passwords:

Subject: [Action Required] Verify your account
From: security@your-saas-provider.co   ← note the .co

Your session expired. Re-authenticate here:
https://accounts-verify.example-login.net/reset

The mismatched domain, the urgency, the generic greeting — those are the tells. But you can't rely on humans catching every one. Treat MFA as the backstop: even a phished password fails without the second factor.

What to actually enforce (developer edition)

MFA everywhere, prefer WebAuthn/passkeys over TOTP over SMS. Phishing-resistant by design.
Email auth records so spoofed senders get flagged:

example.com. TXT "v=spf1 include:_spf.google.com -all"
_dmarc.example.com. TXT "v=DMARC1; p=reject; rua=mailto:dmarc@example.com"

Set DMARC to p=reject once you've monitored with p=none.

A dead-simple reporting path. A phishing@ alias or a Slack /report-phish shortcut beats a 6-step wiki page. Friction kills reporting.
20-minute onboarding briefing for every new hire: what phishing looks like, the red flags, and exactly what to do when they're unsure.

When something slips through

Have a written SMB response plan before you need it: reset the affected credential, revoke active sessions, check auth logs for lateral movement, and notify anyone whose access chains off that account. Rehearse it once — a phished credential at a small business can unlock bank accounts, customer data, and partner networks.

Phishing prevention doesn't need a six-figure budget. It needs structured training, a few technical controls you can ship this week, and a reporting culture that turns employees into your first line of defense.

Originally published on strongpassfactory.com

Password Compliance for SMBs: A Developer's Guide to HIPAA & PCI in 2026

Kokal Limited — Sun, 19 Jul 2026 13:03:59 +0000

If your app touches patient records, card data, or EU customer info, password compliance isn't optional — and the fines are brutal. A single HIPAA violation can run up to $50,000 per incident, and PCI DSS non-compliance can cost you the ability to process cards entirely.

The good news for developers: the requirements across HIPAA, PCI DSS v4.0, and GDPR overlap heavily. Build one solid auth policy and you satisfy multiple frameworks at once.

HIPAA: what auditors actually expect

The HIPAA Security Rule (45 CFR § 164.312) is deliberately vague — it asks for "reasonable and appropriate" safeguards rather than exact character counts. In practice, auditors accept NIST SP 800-63B as the baseline:

12+ character passwords
No forced arbitrary rotation
Breach/compromised-password checking
MFA (now considered the "standard of care" for ePHI)

The concrete technical controls you'll implement:

Unique User ID     → one account per employee, no shared logins
Automatic Logoff   → 5–15 min idle timeout
Emergency Access   → break-glass credential, logged on use
Integrity Controls → audit trails tied to individual credentials
Encryption         → HTTPS everywhere + hashed password storage

On storage — never roll your own. Use a slow, salted hash:

# Argon2id is the current recommendation
from argon2 import PasswordHasher

ph = PasswordHasher()  # sane defaults: memory, time, parallelism
hash = ph.hash("user-supplied-password")
ph.verify(hash, "user-supplied-password")

The penalty scale

HIPAA fines are tiered by culpability, from $100 (did not know) up to $1.5M per violation category (willful neglect, uncorrected). For a 5–15 person clinic, one password-related breach easily means tens of thousands in fines — before notification and reputational costs.

PCI DSS v4.0 & GDPR

If you accept cards, PCI DSS v4.0 layers on similar rules: minimum 12-character passwords, MFA for all access into the cardholder data environment, and no shared accounts.

GDPR's Article 32 never says "password" explicitly, but "appropriate technical measures" is interpreted the same way — strong auth, encryption, and access controls.

One policy to rule them all

Because the frameworks converge, a single implementation covers all three:

✓ 12+ char minimum, screen against breach corpora (HaveIBeenPwned API)
✓ MFA on every account
✓ Argon2id / bcrypt password hashing
✓ Unique per-user credentials + audit logging
✓ Idle session timeout
✓ TLS in transit, encryption at rest

Check that list off and you're compliant across HIPAA, PCI, and GDPR simultaneously — no enterprise budget required.

Originally published on strongpassfactory.com

Vendor Password Security: Third-Party Access for SMBs

Kokal Limited — Wed, 15 Jul 2026 13:11:37 +0000

Not logged in · Please run /login

How We Stopped Password Reuse From Sinking Our Small Team

Kokal Limited — Mon, 13 Jul 2026 13:21:52 +0000

If you work at a small company, you already know the credential situation: five to twenty people, each juggling logins for email, CRM, payroll, cloud storage, and a dozen vendor portals. Some save passwords in the browser. Some keep a spreadsheet. A few just hit "forgot password" every single time.

That's not a workflow — it's a breach waiting to happen.

The numbers are ugly

81% of breaches involve stolen or weak passwords (Verizon 2026 DBIR)
$98,000 average cost per incident for businesses under 50 employees (IBM 2026)
65% of people reuse passwords across work and personal accounts (NCSC)

That last one is the killer. Reuse means one breached marketing SaaS can unlock your entire stack. As developers, we get this intuitively — it's the same reason you never store secrets in plaintext.

What a password manager actually fixes

Think of a business password manager as three controls bundled together:

1. Generation — every account gets a unique secret from a CSPRNG, not Summer2026!:

# what a decent generator does under the hood
openssl rand -base64 24
# => 8f2Kd9xQ1mZ7pL4vR6nT0wYc

2. Storage — encrypted at rest and in transit:

at rest:     AES-256
in transit:  TLS 1.3
access:      authorized team members only

3. Policy enforcement — admins set minimum standards, require MFA on the vault, and audit who touched what.

What to screen for (the dev checklist)

Consumer tools and free personal vaults skip the parts teams need. When evaluating, look for:

Admin console with shared vaults per department (finance, ops, eng)
Role-based access — admin / editor / viewer, not "everyone gets everything"
Instant revocation when someone offboards
Audit logs so credential access is traceable
MFA enforcement on the vault itself

If a tool can't do role-based access and instant revoke, you're back to sharing secrets over Slack — which defeats the entire point.

CISA explicitly recommends password managers as a core control for organizations of any size. Pair one with MFA and you've closed the gap most SMB breaches walk right through.

The takeaway

You don't need an enterprise IT team to fix credential hygiene. Pick a manager with real admin controls, generate unique passwords everywhere, turn on MFA, and audit access quarterly. It's the single highest-leverage security move a small team can make in an afternoon.

Originally published on strongpassfactory.com

Passkeys for SMBs: Going Passwordless in 2026 (A Developer's Guide)

Kokal Limited — Mon, 13 Jul 2026 13:20:39 +0000

If you build or maintain internal tools for a small team, you've probably watched passwords rot from the inside: reused across a dozen SaaS apps, pasted into Slack, parked in a spreadsheet named logins_final_v2.xlsx. Passkeys fix the root cause. Here's the developer-level version of why, and how the flow actually works.

Passwords vs. passkeys, architecturally

A password is a shared secret — you know it, the server knows it, and anything on the wire between you can grab it. A passkey is a FIDO2 credential built on public-key cryptography. Your device holds the private key; the server only ever sees the public key.

That single difference kills whole attack classes:

Phishing — there's nothing to type, and the credential is bound to the origin.
Breach leaks — the server never held your private key.
Credential stuffing — each assertion is scoped to a specific domain, so it can't be replayed.

The flow

Registration stores a public key. Authentication is a challenge/response the server verifies against it:

// Authentication (simplified WebAuthn)
const assertion = await navigator.credentials.get({
  publicKey: {
    challenge: serverChallenge,        // random bytes from your backend
    rpId: "yourapp.com",               // origin-bound: phishing-resistant
    userVerification: "required",      // face / fingerprint / device PIN
  },
});
// Device signs the challenge with the private key.
// Backend verifies the signature against the stored public key.

The private key never leaves the authenticator. No secret crosses the network — just a signature over a one-time challenge.

Why it matters for small teams

You don't need an enterprise identity platform to benefit. In 2026, Google Workspace, GitHub, Slack, and basically every major business app accept passkeys out of the box — no new software, no dedicated IT hire.

The payoff is concrete:

The Verizon 2026 DBIR attributes 81% of breaches to stolen or weak passwords.
IBM's 2026 report puts the average breach cost for sub-50-employee businesses at $98,000.
Google measured passkeys cutting login time by ~40% with a higher first-attempt success rate — which for a small shop means fewer reset tickets and "I'm locked out" pings.

Where passwords still hang around

Passkeys aren't a silver bullet. You'll still want a password (or recovery flow) for account bootstrap, legacy systems without WebAuthn support, and cross-device recovery when someone loses their only authenticator. Treat passkeys as the default and passwords as the fallback, not the reverse.

If you're rolling this out across a team, start by enabling passkeys on your highest-value accounts (email, code host, cloud console) and work outward.

Originally published on strongpassfactory.com

Test Published

Kokal Limited — Mon, 13 Jul 2026 13:14:14 +0000