License key sharing is the number one way pirates distribute paid software. One person buys a key and posts it on a forum — suddenly hundreds of people are using your product for free. HWID locking makes this trivial sharing impossible.
What is HWID Locking?
HWID (Hardware ID) locking binds a license key to a specific physical machine. When a user first authenticates with a license key, BetterAuth captures a cryptographic fingerprint of their hardware. From that point on, the key only works on that specific machine.
If someone copies the key and tries to use it on a different computer, the authentication fails with an HWID_MISMATCH error. The key is useless on any other hardware.
How BetterAuth Generates Hardware Fingerprints
We don't rely on a single identifier — that would be easy to spoof. Instead, BetterAuth combines multiple hardware signals into a composite hash:
- CPU Identifier — Processor model, stepping, and feature flags
- Baseboard Serial — Motherboard serial number from SMBIOS/DMI
- Disk Drive Serial — Primary storage device serial number
- MAC Address — Network adapter hardware address
- BIOS UUID — Universally unique identifier from the system BIOS
These identifiers are concatenated and passed through SHA-256 to produce a deterministic, unique 64-character hexadecimal string. Changing any single component (replacing the hard drive, swapping the motherboard) changes the resulting HWID.
Why Composite Hashes Are Spoof-Resistant
A common attack vector is HWID spoofing — tools that fake hardware identifiers to impersonate another machine. Here's why composite hashes resist this:
- Multiple data sources — An attacker must spoof all five identifiers simultaneously, not just one
- Cross-validation — Some identifiers are interrelated (e.g., motherboard serial and BIOS UUID should be consistent)
- Kernel-level access — Some identifiers require kernel-level access to read correctly, making user-mode spoofing tools unreliable
The Authentication Flow
┌──────────┐ POST /api/v2/license/validate ┌──────────────┐
│ CLIENT │ ──────────────────────────────────► │ BetterAuth │
│ │ { key, secret, hwid } │ Server │
│ │ │ │
│ │ ◄────────────────────────────────── │ HWID match? │
└──────────┘ { success: true/false } └──────────────┘
First login: HWID is NULL → stored automatically
Next logins: HWID compared → match = OK, mismatch = rejected
Handling Legitimate Hardware Changes
Users upgrade their hardware — that's a fact of life. BetterAuth handles this gracefully:
- HWID Reset Limits — Each application can configure how many HWID resets a user is allowed per billing cycle
- Admin Dashboard — You can manually reset any user's HWID from the user management panel
- API Reset — Users can request a reset through your own support flow using the admin API
HWID vs. IP-Based Locking
Some platforms lock licenses to IP addresses. This is problematic because:
- IPs change frequently (DHCP, mobile networks, VPNs)
- Multiple users behind NAT share the same IP
- Geo-location is imprecise and causes false rejections
HWID locking is hardware-bound, not network-bound. A user can switch from WiFi to cellular to VPN and their license still works — because the hardware hasn't changed.
Best Practices for HWID Implementation
- Collect HWID client-side — Never trust an HWID sent from your server; it must come from the user's actual machine
- Use HTTPS — Always send HWIDs over encrypted connections to prevent interception
- Set reasonable reset limits — 2–3 resets per month covers legitimate upgrades while preventing abuse
- Log HWID changes — Monitor for patterns like rapid HWID cycling, which indicates key reselling
HWID locking isn't a silver bullet — determined reverse engineers can bypass it with enough effort. But it raises the bar high enough that most casual pirates will simply buy a license rather than spend days trying to circumvent it.