Preventing SteamID Spoofing on Non-Steam Servers (Reunion + SteamIdHashSalt)

On a Steam server this problem does not exist: Steam validates every ticket, so a STEAM_0:x:xxxx ID is genuine and unique. On a non-steam server it is a real threat — without the right configuration a client can simply claim your head admin's SteamID and inherit full RCON-level access from users.ini. The fix is a secret salt in Reunion plus an admin auth method that cannot be forged. Here is how to close it properly.

1. Understand the attack

Admins are usually granted access by SteamID in users.ini:

"STEAM_0:1:123456" "" "abcdefghijklmnopqrstu" "ce"

On a non-steam server, the SteamID a client presents is only as trustworthy as your auth layer. If IDs are generated in a predictable or client-controlled way, an attacker who learns your admin's ID (it is often visible in status output or logs) can configure their client to present the same one and walk in with your flags. That is SteamID spoofing.

2. Set a strong SteamIdHashSalt in Reunion

Reunion generates SteamIDs for non-steam clients by hashing client identity together with a server-side secret, the SteamIdHashSalt, set in reunion.cfg in your cstrike folder:

SteamIdHashSalt = a_long_random_secret_string_16plus

Two hard rules:

• It must be at least 16 characters — Reunion refuses to load a salt shorter than that, and a short salt is guessable anyway. Use a long random string.
• Keep it secret and stable. The salt is what makes generated IDs unpredictable to an attacker. If it leaks, they can reproduce IDs; if you change it, every generated ID changes and all your SteamID-based admins lose access at once.

With a strong, secret salt, a client can no longer reverse-engineer or trivially reproduce another player's generated ID.

3. Understand Reunion's auth providers

Reunion recognizes clients from several providers (real Steam, its own generated non-steam IDs, and legacy revemu-style clients). The generated-ID path is the one the salt protects. Configure Reunion to accept the providers you actually want and to hand each client a salted, generated ID rather than trusting a client-supplied one. Read the provider settings in your reunion.cfg — do not accept a mode that lets the client dictate its own SteamID unchecked.

4. Authenticate admins by something unspoofable

Even with a good salt, the most robust protection for high-privilege admins is to not rely on SteamID alone. AMX Mod X supports password authentication: the admin sets a client-side setinfo value and users.ini requires it. Use the flags that demand a password rather than pure SteamID matching:

// users.ini entry that requires a password (flag "a" = do not check steamid,
// authenticate by the name+password fields instead)
"MyAdminName" "SecretPass" "abcdefghijklmnopqrstu" "a"

// the admin sets this in their client config
setinfo _pw "SecretPass"

Now an attacker who knows the SteamID still cannot get in without the password. Reserve this for the accounts that matter most; the exact flag semantics are in the access flags reference, and adding admins in the add-admin guide.

5. Fix duplicate IDs while you are here

Spoofing's cousin is collision: many cracked clients ship the same default SteamID, so without generation everyone shares one identity and bans and admin become meaningless. A correct salted Reunion setup gives each client a distinct ID — the same mechanism that stops spoofing also fixes duplicate SteamIDs.

Troubleshooting

• Reunion will not load — the salt is shorter than 16 characters, or reunion.cfg is malformed. Lengthen the salt and check the syntax.
• All admins lost access at once — you changed SteamIdHashSalt, which regenerated every non-steam ID. Either restore the old salt or re-add admins under the new IDs.
• An impostor still got admin — you are authenticating by SteamID only and the salt leaked or the mode trusts client IDs. Move critical admins to password auth.
• Password admin cannot authenticate — the client setinfo _pw does not match users.ini, or the entry lacks the "authenticate by password" flag. Both sides must agree; see amxx.cfg and the password field.

Verification

Have a trusted second person connect from a non-steam client and read their ID in status — it must be unique, not shared with anyone else. Then, from a clean test client, deliberately try to present your admin's SteamID: with a strong secret salt and password-authenticated admins, that client must not receive admin flags. Confirm your real admin still authenticates (with the password if you configured one). If any spoof succeeds, treat the salt as compromised, rotate it, and move privileged accounts to password auth.