1. Overview
Authvaultix
  • Getting Started
  • Overview
    • Security Practices
    • SDK & Code Examples
    • ? QnA
    • rate limiting
  • Dashboard
    • Manage Applications
    • Account Settings
      • Settings
      • Billing History
      • Login History
      • Notifications
      • Keyboard Shortcuts
      • Preferences
      • Forms
      • Bug Bounty
    • Seller
      • Team Member
      • Seller Keys
      • Seller Logs
    • App
      • Licenses
      • Users
      • Token
      • Subscriptions
      • Chats
      • Sessions
      • Webhook
      • Files
      • Global Variables
      • User Variables
      • Logs
      • Blacklists
      • Whitelists
      • Audit Logs
      • Web Loader
      • Tamper Log
  • API
    • initialization
      • init
    • Authentication
      • Login
      • register
      • License Login
      • Forgot Password
      • OTP Verify
      • Logout
      • Change Username
    • Sessions
      • Session Check
      • Fetch Online
    • Licensing
      • Upgrade Access
    • Users
      • Get User Variable
      • Set User Variable
      • Global Variable
      • Ban User
      • Check Blacklist
    • Files
      • Download File
    • Chat
      • Send Message
      • Fetch Messages
    • Webhooks
      • Webhook
    • Security
      • Tamper Detection
  • Seller API
    • Seller Key
      • Validate Seller Key
    • Users
      • Add HWID To Existing User
      • Create User
  1. Overview

Security Practices

⛨ Security Practices#

Security Tips#

⚠️ Important Security Note: AuthVaultix secures your software authentication, licensing, and server communication with cryptography. But developers also need to take proactive steps to protect the client executable from memory analysis and reverse-engineering. AuthVaultix is an Authentication Service, not a binary Obfuscation Service.

Built-in AuthVaultix Protections#

When you use the official AuthVaultix Client API wrappers, these protections are enabled automatically:
HMAC-SHA256 Signed Responses: Every response JSON returned by the server is signed in the HTTPS signature header. The client calculates the local signature and verifies it against the header — attackers cannot forge a fake "success" response without the secret key.
Nonce & Replay Protection: Every server payload includes a unique cryptographic nonce to prevent replay attacks.
Session Expiry & Token Revocation: Inactive or compromised sessions expire automatically.

What You Should Do as a Developer#

1.
Never Remove Signature Checks: Do not remove signature verification, nonce validation, or server response validation from your code.
2.
Implement SSL Certificate Pinning: Harden your client by hardcoding AuthVaultix SSL public key hashes so proxy tools like Fiddler or Charles cannot intercept traffic with a forged root certificate.
3.
Spread Security Checks: Don’t just verify authentication on startup. Run checks across modules, such as periodic background verification every 1-2 minutes.
4.
Do Not Hardcode Secrets: Never embed sensitive API tokens, encryption keys, or URLs in a client binary. Store them in AuthVaultix Global Variables or User Variables instead.
5.
Obfuscate & Pack Your Binary: Protect the client with advanced obfuscation, anti-debugging, anti-injection, and packers such as VMProtect, Themida, or .NET Reactor.

GUID Setup & Signature Protocol#

When the AuthVaultix client sends the initialization request (/api/1.0/), it must include a random 36-character GUID in the enckey parameter. This GUID is only used for the init request.

1. Initial Signing Key Derivation#

On the server, the init response signing key is derived from the GUID and the Application Secret:
Example:
Client GUID: 9f7c2a18-e3d4-4b91
App Secret: d9f0c7e4b1a86f35e91d72c84a5b16f0c9e3a17d54b8f26c91a4e7d32b6f5a81
Init Response JSON Payload:
{
    "success": true,
    "code": 68,
    "message": "Initialized",
    "sessionid": "bcc76815e57af5f2",
    "appinfo": {
        "version": "1.0",
        "customerPanelLink": "https://authvaultix.com"
    },
    "newSession": true,
    "nonce": "82c28c405f991892d96e9f73ce2edb2d",
    "ownerid": "5d36476ca4"
}
HTTPS Signature Header:
signature: 5f91c2d8a4e73b1c9f65d08ea72b4f9183a7e6c1d4b95f20a8c73e51f2d9b684
Client application is received JSON response par local HMAC-SHA256 calculate karti hai using derived SignKey. Agar signatures match hote hain, toh proceed karein, varna application immediate terminate kar dein.

2. Subsequent Requests Signature Protocol#

Init request complete hone ke baad baaki sabhi requests (login, license-login, getvar) ke liye full key use hoti hai:
Login Response JSON Payload Example:
{
    "success": true,
    "code": 68,
    "message": "Logged in!",
    "info": {
        "username": "zx",
        "subscriptions": [
            {
                "subscription": "default",
                "key": "",
                "expiry": "1785098520",
                "timeleft": 69117
            }
        ],
        "ip": "152.56.134.242",
        "hwid": "F92A-5702-B3A1-9143-9206-CA45-4366-B6B5-B12E-A8DF-22B1-3E24-8660-84A0-1769-AB65",
        "createdate": "1785012158",
        "lastlogin": "1785029403"
    },
    "permissions": [
        "default"
    ],
    "nonce": "04df0548d59d6d1c",
    "ownerid": "5d36476ca4"
}
Received Header Signature:
signature: 7c41e9a5d8b3f1c0672e94af5b81d03fc6a9e8721450bc3d9f7a6812e5c4d0b9
The client calculates local HMAC-SHA256 using SessionKey. If the calculated signature does not match the received signature, reject the response and trigger your anti-bypass routine immediately.
Modified at 2026-07-26 01:46:22
Previous
Getting Started
Next
SDK & Code Examples
Built with