# Security Practices

---
title: "Security Practices & Cryptographic Architecture"
description: "Built-in AuthVaultix security features, HMAC-SHA256 response signing, GUID setup, and developer security best 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:

$$\text{SignKey} = \text{substring}(\text{GUID} + \text{'-'} + \text{AppSecret}, 17, 64)$$

**Example:**
- **Client GUID:** `9f7c2a18-e3d4-4b91`
- **App Secret:** `d9f0c7e4b1a86f35e91d72c84a5b16f0c9e3a17d54b8f26c91a4e7d32b6f5a81`

**Init Response JSON Payload:**
```json
{
    "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:

$$\text{SessionKey} = \text{GUID} + \text{'-'} + \text{AppSecret}$$

**Login Response JSON Payload Example:**
```json
{
    "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.