Purity Plugin Serial Number And Authorization Code Access

Report: Purity Plugin — Serial Number and Authorization Code

6. Privacy & Compliance

• Minimize personal data in license payloads; use customer IDs instead of PII.
• Comply with applicable data protection laws when storing customer info (encryption, retention limits).
• Provide customers a mechanism to request license records or deletion where required.

8. Recommendations

• Use signed authorization codes (ECDSA) rather than simple alphanumeric tokens.
• Implement both online and offline validation modes.
• Store signing keys in an HSM/KMS; rotate periodically.
• Provide a secure self-service portal for license management and revocation.
• Log and monitor activation patterns to detect abuse.

Overview

This report documents the Purity plugin's serial number and authorization code handling, including format, storage, generation, validation, security considerations, and recommendations for management and troubleshooting.

5. Security Considerations

• Prevent forgery:
  • Use cryptographic signatures; never rely on obfuscation.
• Prevent replay/abuse:
  • Track activations per code and enforce limits server-side.
  • Bind codes to hardware fingerprint for stricter enforcement (with privacy considerations).
• Revocation:
  • Maintain revocation list and support immediate server-side blacklisting (online checks).
• Tamper detection:
  • Versioned checksums and signature coverage for both code and local license files.
• Incident response:
  • Revoke compromised keys immediately and re-issue replacements; notify affected customers.

3. Validation Mechanisms

• Local validation:
  • Verify signature of authorization code.
  • Check payload fields: serial matches installed serial (if present), not expired, feature flags compatible.
  • Validate checksum to detect corruption.
• Online validation (recommended):
  • Occasional activation check-in with license server to enforce revocation, activation limits, or subscription status.
  • Use short-lived tokens or refresh tokens for periodic re-validation (e.g., every 30–90 days).
• Offline fallback:
  • Allow offline activation via signed codes with issuance and expiry embedded; require re-validation when connectivity restored.