Independent Application Developers Network

Login|Join

Our Blog

Checking for Compromised Passwords with the Pwned Passwords API

By Steve Wood - August 12, 2026

Article Summary (See Full Article)

If you collect passwords in a web application, it's worth checking them against Troy Hunt's [Pwned Passwords](https://haveibeenpwned.com/Passwords) database — a list of hundreds of millions of passwords exposed in real-world data breaches. If a user's chosen password shows up there, it's a bad password no matter how "strong" it looks, because it's already in every credential-stuffing wordlist attackers use.

The good news: you never send the actual password (or even its full hash) to the API. Here's how the check works, and how to implement it in both **Xbasic (Alpha Anywhere)** and **Python**.

How the API Works (k-Anonymity Model)

  1. Take a SHA-1 hash of the plaintext password.
  2. Send only the **first 5 characters** of that hash to the API: `GET https://api.pwnedpasswords.com/range/{first5}`
  3. The API returns every known compromised hash suffix that starts with those 5 characters — typically several hundred — each with a count of how many times it's appeared in breaches.
  4. You compare the **remaining 35 characters** of your local hash against that list. If there's a match, the password is compromised.

Because you only ever transmit a 5-character prefix, the API never sees enough of the hash to reconstruct the original password, and Have I Been Pwned has no way of knowing which specific password you checked.

Xbasic (Alpha Anywhere) Implementation

Compute the SHA-1 hash client-side (via JavaScript), send only the first 5 characters to the range endpoint, and search for the remaining 35 characters in the response body:

xbasic
  • hash_newPassword = upper(e.dataSubmitted.hash_newPassword)
  • hash_newPassword35 = right(hash_newPassword,35)
  • url = "https://api.pwnedpasswords.com/range/" + left(hash_newPassword,5)
  • result = http_get(url)
  • hashlist = result.body 
if AT(hash_newPassword35,hashlist) > 0 ' found
    err_msg = "This password is not allowed because it was found in a list of known compromised passwords."
    goto endofscript
end if

A couple of implementation notes worth calling out for anyone adapting this:

  • **`upper()` matters.** The API returns hashes in uppercase hex, so make sure whatever computed `hash_newPassword` client-side is also uppercase before comparing.
  • **`AT()` does a substring search**, not a line-by-line match. Since each returned hash suffix is a fixed 35 characters, a substring match is safe here — you won't get a false positive from a coincidental match spanning two lines.
  • If you'd rather hash server-side instead of trusting a client-supplied hash, Xbasic doesn't have a built-in SHA-1 function, so you'd need to shell out or use a UDF/DLL. Hashing in JavaScript before submit (as you're doing) is the simpler path.
  • Consider wrapping the `http_get()` call in error handling — if the API is unreachable, you probably want to let the password through rather than block registration entirely (fail open on availability, fail closed on validation).

Python Implementation

```python
import hashlib
import requests

def is_pwned(password: str) -> bool:
    sha1 = hashlib.sha1(password.encode("utf-8")).hexdigest().upper()
    prefix, suffix = sha1[:5], sha1[5:]

    response = requests.get(
        f"https://api.pwnedpasswords.com/range/{prefix}",
        headers={"Add-Padding": "true"},  # optional: mitigates response-size timing attacks
        timeout=5,
    )
    response.raise_for_status()

    for line in response.text.splitlines():
        candidate_suffix, count = line.split(":")
        if candidate_suffix == suffix:
            return True  # found in breach corpus

    return False


if __name__ == "__main__":
    pwd = "password123"
    if is_pwned(pwd):
        print("This password has appeared in a data breach — choose another.")
    else:
        print("Password not found in known breaches.")
```

A few notes:

  • `hashlib.sha1` gives you the hash in one line; no external dependencies beyond `requests`.
  • The API's `Add-Padding: true` header returns a randomized number of extra fake entries, which helps defend against attackers trying to infer the *real* breach count for a given prefix based on response size. It doesn't affect your matching logic.
  • The `count` value returned alongside each hash (`candidate_suffix, count = line.split(":")`) tells you how many times that password has been seen in breaches — you can log or surface that number if you want to give users more context than a flat reject.
  • Same fail-open/fail-closed consideration applies: decide up front what happens if `requests.get()` times out or errors.

Wrapping Up

Both implementations follow the same three steps — hash, truncate, compare — and neither ever exposes the plaintext password or a reversible hash over the wire. It's a small addition to a registration or password-change flow, and it closes off one of the more common ways accounts get compromised: reusing a password that's already sitting in an attacker's wordlist.



Why Alpha Anywhere Deserves a Place on Every Developer's Short List

By Steve Wood - July 20, 2026

Article Summary (See Full Article)

Key Takeaways

  • Application-First Philosophy: Unlike traditional frameworks (.NET, React, Django) that start with manual plumbing, Alpha Anywhere provides built-in application infrastructure automatically (CRUD operations, security, forms, reports, data validation).
  • Hybrid Low-Code & Full Extensibility: Developers can start rapidly using low-code components and seamlessly integrate standard languages (JavaScript, SQL, Xbasic, Python, CSS, REST APIs) whenever deep customization is required.
  • Solo Developer & Small Team Efficiency: Designed for independent consultants and small teams, it allows a single developer to build complete enterprise systems without needing separate front-end, back-end, database, and DevOps specialists.
  • Data-Centric Focus & Modernization: Excels at data-driven business applications and enterprise database integration (SQL Server, MySQL, MariaDB, PostgreSQL). It serves as a natural upgrade path for aging Microsoft Access, FoxPro, or FileMaker systems.
  • AI Collaboration: Modern AI coding tools reduce the friction of learning platform-specific syntax (like Xbasic), generating supporting code while keeping Alpha Anywhere as the core application framework.

When to Use vs. When to Avoid

Ideal Use Cases Less Suited For
Rapidly building secure, data-driven business applications. Massive consumer-facing networks (e.g., social media with millions of users).
Independent developers, consultants, and SMBs. Organizations with rigid, highly standardized .NET or Java DevOps pipelines.
Modernizing legacy desktop databases (Access, FoxPro, Clarion). Pure UI-heavy web applications requiring minimal backend business logic.

Bottom Line: Alpha Anywhere remains a top-tier, low-overhead platform for professional developers who prioritize building, deploying, and maintaining reliable business applications efficiently.



Why Seasoned Full-Stack Developers Still Matter in the Age of AI

By Steve Wood - July 15, 2026

Article Summary (See Full Article)

Key Takeaways

  • Building Software vs. Writing Code: Producing code is just a task, whereas software engineering requires systems thinking—modeling data upfront, designing consumable APIs, making trade-off architectural decisions, and knowing when not to build.
  • Selective AI Usage as a Strategy: Experienced developers use AI like a power tool for mechanical tasks (boilerplate, test scaffolding, syntax references), but deliberately solve complex problems by hand (debugging, schema design, architecture) to build and protect their own expertise.
  • The Compounding Skill Gap: Over-relying on AI creates developers who can output code but cannot debug or defend design choices. Conversely, using AI selectively sharpens high-level judgment and deepens mental models over time.
  • Development as a Craft: Software engineering combines technical science with aesthetic judgment. Navigating uncomfortable, non-obvious bugs builds earned understanding that fast answers cannot replace.
  • Durable Value in the AI Era: AI acts as an accelerant for foundational knowledge rather than a replacement. Organizations still critically need senior engineers who can transform vague problems into strategy, own end-to-end systems, and make defensible decisions under uncertainty.

Senior Developers vs. Over-Reliant AI Users

Seasoned Craftsmen (Selective AI) Over-Reliant Developers (Crutch AI)
Uses AI for repetitive, well-understood mechanics and boilerplate. Delegates complex problem-solving and architectural decisions entirely to AI.
Builds deep mental models by working through hard bugs by hand. Plateaus early because AI replaces the struggle required for true understanding.
Can debug, maintain, and defend system designs under pressure. Produces quick artifacts but struggles to debug or justify generated code.

Bottom Line: AI tools amplify existing expertise but cannot substitute for systems thinking, architectural judgment, and earned experience—making seasoned full-stack developers more valuable, not less.



How the Ziel Dashboard Addresses Federal and EU Regulations and Guidelines

By Steve Wood - July 05, 2026

Article Summary (See Full Article)

Key Takeaways

  • Regulatory Scope: Ziel provides Radio Frequency microbial remediation for agricultural, food processing, and cannabis producers. Beyond machine hardware, regulatory bodies like the US FDA and EU EMA strictly regulate the electronic records surrounding production.
  • Built-In Compliance Baseline: The Ziel Dashboard was engineered from the ground up to address FDA 21 CFR Part 11 and EU GMP Annex 11 regulations, ensuring digital records carry the legal weight of paper records and handwritten signatures.
  • Automated Audit & Error Trapping: Features server-side, tamper-resistant field-level audit logging, session tracking, and a two-stream Python error-trapping pipeline (validating incoming CSV equipment logs and lab Certificates of Analysis before writing to the database).
  • Robust Access & Password Security: Enforces invite-only user provisioning, role-based security, 15-minute inactivity timeouts, real-time remote session termination (via Pusher.com), and NIST SP 800-63B compliant passwords checked against HaveIBeenPwned.
  • Transatlantic Alignment (EU GMP Annex 11): Core technical controls automatically satisfy EU regulations, with planned third-party e-signature API integration designed to cover both FDA e-signatures and EU eIDAS Advanced Electronic Signatures (AdES).

FDA 21 CFR Part 11 Criteria & Ziel Dashboard Status

FDA Criterion Ziel Dashboard Implementation Compliance Status
1. System Validation Built on a platform offering infrastructure IQ/OQ/PQ protocols; application workflows engineered for testability and reproducibility. In Progress
2. Audit Trails Server-side, computer-generated, time-stamped logs capturing all field-level database edits, user IDs, and login attempts without edit/delete rights. Fully Met
3. Access Controls Invite-only user roles, HaveIBeenPwned password hashing, configurable MFA (AAL2 via TOTP), 15-min timeout, and real-time session kill switch. Fully Met
4. Operational Checks Python processing pipeline error-traps equipment CSVs and lab CoAs before database commits, requiring documented reasons for manual corrections. Fully Met
5. Electronic Signatures Captures login terms and audit attribution; formal record approval e-signatures planned via 3rd-party API integration (supporting FDA and EU eIDAS). Planning Stage

Bottom Line: The Ziel Dashboard meets regulatory mandates not through superficial add-ons, but through deep system-level architecture—enabling food, cannabis, and agricultural operators to maintain audit-ready, compliant digital records effortlessly.



SSL Certificate Lifespans Are Shortening in 2026: What Independent Developers Need to Know

By Steve Wood - February 18, 2026

Article Summary (See Full Article)

Key Takeaways

  • Industry Shift to Shorter Lifespans: Following historic reductions from 825 days to 398 days, major browser vendors (Google, Apple, Mozilla) are pushing public SSL/TLS certificate validity down to 90 days (or shorter) starting in May 2026.
  • Security Justifications: Short-lived certificates minimize the window of exposure for compromised private keys, accelerate ecosystem adoption of modern cryptographic standards, and force organizations to eliminate manual certificate management.
  • The Real Benefit (Forced Automation): While attackers usually exploit stolen keys immediately rather than waiting months, the primary practical advantage of 90-day lifespans is forcing developers to adopt reliable automated renewal tools (e.g., Certbot, win-acme, Traefik, Caddy).
  • Minimal Impact on Alpha Cloud Users: Alpha Anywhere applications hosted on Alpha Cloud handle certificate issuance, renewal, and deployment automatically, requiring zero developer intervention.
  • Call to Action for Self-Hosters: Developers running Alpha Anywhere on their own IIS, Apache, or reverse proxy servers must transition away from annual manual purchases (e.g., commercial OV/EV certificates) and implement automated Let's Encrypt workflows.

Deployment Environment Comparison

Hosting Setup Operational Impact of 2026 Shift Recommended Action
Alpha Cloud Hosting None — SSL management is completely handled by the platform infrastructure. No action required.
Self-Hosted (Let's Encrypt) Minimal — System is already configured for 90-day automated renewals. Verify ACME client / renewal scripts are functioning properly.
Self-Hosted (Manual Commercial SSL) High — Manual yearly renewals become impractical with shortened validity periods. Migrate to automated Let's Encrypt setups (win-acme/CertifyTheWeb) or proxy automation.

Bottom Line: The move to 90-day SSL lifespans makes manual certificate management obsolete; independent developers must embrace automated PKI tools or fully managed hosting like Alpha Cloud.



Why Actively Maintaining Your Company Database Is Critical

By Steve Wood - August 25, 2025

Article Summary (See Full Article)

Key Takeaways

  • Core Asset Protection: A company’s relational database is its primary operational brain; neglecting routine maintenance leads to query slowdowns, bloated storage, index fragmentation, and hidden data corruption.
  • Preventative Performance & Scaling: Proactive maintenance—including regular index reindexing, query plan optimization, log truncation, and routine table vacuuming/defragmentation—prevents sudden system bottlenecks before they disrupt business workflows.
  • Data Integrity & Disaster Recovery: True maintenance goes beyond simple nightly backups; it requires verifying backup restorability, managing transaction logs, enforcing constraints, and catching corrupt records early.
  • Security & Compliance Risk Reduction: Regular database upkeep ensures access permissions stay current, unused service accounts are purged, security patches are applied, and sensitive historical records comply with data retention policies.
  • Cost Savings: Fixing database degradation proactively is significantly cheaper than diagnosing an emergency outage, repairing corrupted tables during business hours, or upgrading to expensive hardware to mask poor database health.

Proactive Maintenance vs. Reactive Management

Proactive Maintenance Strategy Reactive "Break-Fix" Approach
Scheduled index defragmentation, query optimization, and log cleanup. Masking slow queries by throwing expensive hardware or extra RAM at the server.
Routine test restorations to verify backup integrity and RTO/RPO targets. Assuming backups work until a catastrophe strikes and recovery fails.
Continuous security audits, role pruning, and patch management. Addressing security vulnerabilities only after a breach or audit failure occurs.

Bottom Line: Regular database maintenance is not an optional IT chore—it is a vital business discipline that protects performance, secures core assets, and prevents catastrophic operational downtime.



Alpha Anywhere + Python: Building Smarter, More Powerful Applications Together

By Steve Wood - August 04, 2025

Article Summary (See Full Article)

Key Takeaways

  • Synergistic Tech Stack: Combining Alpha Anywhere’s low-code rapid UI, security, and database infrastructure with Python’s massive ecosystem creates a highly versatile architecture for business software.
  • Division of Labor: Alpha Anywhere acts as the front-end and application hub—handling web components, mobile UI, authentication, and CRUD operations—while Python runs background jobs, complex data processing, statistical tasks, and AI integrations.
  • Leveraging Python’s Ecosystem: Developers can tap directly into Python's specialized libraries (such as Pandas, OpenPyXL, Scikit-learn, and Requests) for tasks that are traditionally difficult or slow to write in native low-code script languages.
  • Integration Mechanisms: Communication between the two systems is typically handled seamlessly via direct CLI/shell execution, server-side Node.js sub-processes, or lightweight REST APIs (built with FastAPI or Flask).
  • Faster Modernization: This paired approach allows independent consultants and developers to rapidly build feature-rich enterprise tools without writing custom front-end scaffolding or re-inventing complex backend math and data pipelines.

Alpha Anywhere vs. Python Role Division

Alpha Anywhere (Application Layer) Python (Processing & Intelligence Layer)
User Interfaces, responsive forms, and mobile layouts. Heavy data analysis, manipulation, and statistical processing (Pandas, NumPy).
Authentication, role-based access controls, and session state. Machine learning, natural language processing, and AI workflows.
Direct relational database binding and rapid CRUD workflows. Complex PDF generation, Excel parsing/transformation, and file scraping.

Bottom Line: Pairing Alpha Anywhere with Python bridges the gap between rapid application delivery and advanced backend capability—giving developers the full power of modern data science and automation wrapped in a secure, business-ready UI.



From Employee Coder to Independent Solution Provider

By Steve Wood - July 11, 2025

Article Summary (See Full Article)

Key Takeaways

  • Mindset Shift from Task-Runner to Partner: Transitioning from an employed programmer to an independent solution provider requires shifting focus from implementing technical tickets to understanding business outcomes, ROI, and client risk.
  • The Power of Full-Stack Ownership: Successful independent consultants don't just write functions; they own entire client relationships—handling requirements gathering, data modeling, security, deployment, and long-term support.
  • Choosing the Right Tech Stack: To thrive solo without a large engineering team, independent providers leverage highly efficient low-code and automation tools (like Alpha Anywhere, Python, and SQL) to deliver rapid enterprise-grade results with low overhead.
  • Value-Based Positioning over Hourly Coding: Clients do not pay independent solution providers for lines of code or raw hours worked, but for solving high-stakes operational problems, reducing downtime, and modernizing business systems.
  • Building Sustainable Client Relationships: Longevity as an independent consultant depends on proactive communication, clear documentation, reliability under pressure, and ongoing application maintenance rather than "one-and-done" software handoffs.

Employee Coder vs. Independent Solution Provider

Employee Coder Independent Solution Provider
Executes pre-defined tasks, tickets, and features within an existing team. Identifies core business problems and formulates end-to-end technical strategy.
Focuses primarily on code syntax, frameworks, and personal execution. Focuses on business value, system architecture, security, and project ROI.
Relies on surrounding infrastructure (DBAs, DevOps, product managers). Leverages high-productivity stacks to independently manage full system lifecycle.

Bottom Line: Moving from an employee programmer to an independent solution provider isn't just about changing who pays you—it's about becoming a trusted partner who delivers complete business outcomes rather than raw code.



Q & A about HIPAA, GDPR, PCI compliant Software

By Lee Vasic - October 01, 2022

Article Summary (See Full Article)

Key Takeaways

  • Compliance at the Application Level: Meeting regulatory frameworks like HIPAA, GDPR, and PCI-DSS isn't just an infrastructure or hosting concern—software architectures must directly incorporate compliance mechanisms like end-to-end encryption, strict access controls, and detailed auditing.
  • Core Regulatory Protections:
    • HIPAA: Focuses on protecting Protected Health Information (PHI) through technical safeguards, transmission security, and formal Business Associate Agreements (BAAs).
    • GDPR: Emphasizes privacy rights for EU citizens, enforcing strict consent, data minimization, right-to-be-forgotten capabilities, and international data transfer controls.
    • PCI-DSS: Governs payment card security, strictly prohibiting the storage of sensitive authentication data (e.g., CVVs) and enforcing segmented network security.
  • Technical Controls & Best Practices: Achieving compliance requires role-based access control (RBAC), multi-factor authentication (MFA), immutable timestamped audit logs, server-side data validation, and encryption both in transit (TLS 1.3) and at rest (AES-256).
  • Shared Responsibility Model: Cloud providers (like AWS, Azure, or Alpha Cloud) secure the underlying physical and cloud infrastructure, but the developer remains fully responsible for application code, user access levels, and data workflows.

Regulatory Framework Comparison

Framework Primary Domain Focus Key Technical Application Requirements
HIPAA US Healthcare Data (PHI) Encrypted record storage, role-based access controls, automatic session timeouts, and comprehensive audit logs.
GDPR EU Personal Data & Privacy Explicit consent tracking, user data export capabilities, and secure "right to erasure" data deletion workflows.
PCI-DSS Payment Card Information Payment gateway tokenization, masked cardholder data, zero storage of CVVs, and strict network segmentation.

Bottom Line: Building compliant software requires an intentional "security-by-design" approach—integrating encryption, access controls, and auditing directly into the codebase rather than treating compliance as an afterthought.



Exploiting the Chrome debugger to help Alpha Anywhere developer to visually enhance user experience

By Doron Farber - February 21, 2022


Article Summary (See Full Article)

Key Takeaways

  • Overview of the Threat Vector: Modern browser developer tools (such as Chrome DevTools) are powerful execution environments. If left exposed or mishandled, attackers can leverage remote debugging protocol ports to inspect application state, hijack web sessions, and execute unauthorized code.
  • How Exploitation Occurs: Attackers target exposed Remote Debugging Ports (e.g., --remote-debugging-port=9222) or use malicious browser extensions and cross-site scripting (XSS) to attach to active debugging sessions, exposing WebSocket controls.
  • Security Risks for Web Applications:
    • Session Hijacking: Extraction of sensitive session tokens, cookies, and local storage variables directly from active browser memory.
    • DOM Manipulation: Injecting malicious scripts into authenticated user sessions to bypass UI controls and security checks.
    • Data Exfiltration: Capturing real-time network traffic, API keys, and sensitive form inputs before transport encryption takes place.
  • Mitigation & Hardening Strategies: Disabling remote debugging in production client deployments, enforcing strict Content Security Policies (CSP), binding debug ports strictly to localhost (127.0.0.1) when in use, and implementing client-side anti-debugging techniques where necessary.

Development vs. Production Security Controls

Development Environment Production Environment (Hardened)
Remote debugging flags enabled for inspectability and rapid testing. All remote debugging flags and developer diagnostic endpoints strictly disabled.
Debug interfaces bound to local network interfaces or default ports. Debug interfaces restricted, bound strictly to loopback interfaces, or removed entirely.
Verbose console logging and unminified source maps exposed. Console logging stripped, source maps hidden/restricted, and robust CSP enforced.

Bottom Line: Browser debuggers are double-edged swords—while indispensable for developers, leaving debugging capabilities exposed in production web applications invites severe security risks and session exploitation.