--- title: "Ace of Spades Revival Player Identity" description: "Understand Ace of Spades Revival accounts, signed guest profiles, original Steam owner validation, unique nicknames, join tickets, and leaderboard trust." canonical: "https://aosplay.net/account" markdown: "https://aosplay.net/docs/account.md" last_updated: "2026-07-16" content_type: "TechArticle" keywords: ["Ace of Spades account","Ace of Spades Steam authentication","BattleSpades guest mode","Ace of Spades leaderboard profile","Protocol 168 SteamSessionTicket"] --- # Ace of Spades Revival Player Identity > Understand Ace of Spades Revival accounts, signed guest profiles, original Steam owner validation, unique nicknames, join tickets, and leaderboard trust. The revival identity system gives every connection a durable player record without forcing every player through the same credential method. A revival username and password works across the site and launcher, a signed installation provides immediate guest play, and original Steam customers keep the retail client’s native session-ticket path. ![Ace of Spades engineer reading plans beside a desert voxel construction project](https://aosplay.net/game/ui/ace-of-spades-battle-builder-construction.jpg) _Three credential routes resolve to one player record: revival password, signed guest installation, or validated original Steam ownership._ ## At a glance | Value | Meaning | | --- | --- | | 3 | supported identity routes | | 10 MIN | default one-use join-code lifetime | | ARGON2ID | password hashing | | 105 | retail Steam ticket packet | ## Credentials prove access; the player record owns progress A nickname is presentation, not proof of identity. The database assigns an internal UUID, a public opaque player ID, and a legacy-compatible numeric ID. Credentials live in separate records and resolve to that player. Statistics, moderation state, and leaderboard history attach to the player record instead of a mutable name. This separation lets a guest upgrade to a password account without losing history and lets a Steam owner participate without inventing a revival password. It also leaves room for carefully reviewed account linking later without rewriting the score model. ## Revival username and password Revival usernames are unique case-insensitively and double as in-game nicknames. They use 3–24 ASCII letters, numbers, or underscore, begin with a letter, and cannot use reserved project or guest prefixes. Passwords are accepted only over the HTTPS API and hashed with Argon2id before storage. The service returns an opaque session: an HttpOnly SameSite cookie for the website or a bearer token for the launcher. Session tokens are random and stored only as SHA-256 hashes in PostgreSQL. - No email address or real name is required - Passwords must contain 12–128 characters - A one-time offline recovery code replaces email-based reset - Changing or recovering a password revokes existing sessions - Database-backed rate limits apply across app instances ## Guest play without a hardware identifier The launcher generates an Ed25519 key pair for a guest installation. The private key remains on the player’s device. To reconnect, the launcher signs a short-lived server challenge; the service stores only the public key and a SHA-256 fingerprint. New guest records receive a random Guest-XXXXXXXX nickname. The reserved prefix prevents confusion with registered callsigns. Guests are deliberately unranked until upgraded, but their local history can remain attached to the same player record during an upgrade. > **Privacy choice — A random key is better than an HWID.** Hardware fingerprints are difficult to rotate, can be unexpectedly identifying, and still can be spoofed. A locally generated signing key proves continuity without inventorying the player’s machine. ## Original Steam owners remain first-class players The retail client sends Protocol 168 packet 105 immediately after ENet connection. Its payload is a little-endian 32-bit ticket length followed by that many opaque Steam authentication bytes. Because this packet has no separate SteamID and the recovered 2014 wrapper exposes the old connect-auth lifecycle, unmodified retail compatibility uses the matching Steam Game Server legacy flow: SendUserConnectAndAuthenticate returns the candidate SteamID, then GSClientApprove or GSClientDeny makes the final decision. A modern GetAuthSessionTicket/BeginAuthSession flow is a separate option only when a claimed SteamID is carried through an authenticated side channel; the old and new APIs must not be mixed in one session. After Valve validates the ticket for the allowed original AppID, a trusted server bridge sends the master service the verified SteamID64, AppID, callback timestamp, server ID, and only a SHA-256 ticket digest. The master never stores the raw ticket. It creates or resolves a Steam-backed player whose legacy numeric ID is the SteamID64, preserving compatibility with the retail profile and leaderboard requests. A client-supplied SteamID, persona name, ticket digest, or Spacewar identity is not proof of ownership. The private bridge endpoint accepts only a fresh attestation from a controlled server that actually received GSClientApprove for the retail flow or ValidateAuthTicketResponse with OK for the modern flow. **Retail packet 105 application payload** ~~~text 69 packet_id = 105 NN NN NN NN ticket_size, u32 little-endian [.. N opaque bytes ..] Steam session ticket ~~~ ## A client never awards its own score After website or launcher authentication, the client requests a short-lived join ticket scoped to one server. The dedicated server consumes it once and receives the canonical player record. Original Steam connections reach the same record through the validated packet-105 path. Only an authenticated dedicated server can submit a match event. Events carry an idempotency key so retries cannot double-award statistics. The service ignores a client-provided display name when a canonical account nickname is available and uses the database identity as the leaderboard key. 1. **Authenticate.** Verify a password, guest signature, or Valve session ticket. 2. **Resolve.** Map the successful proof to exactly one durable player record. 3. **Bind.** Lock a short-lived join ticket or Steam session to the target game server. 4. **Ingest.** Accept idempotent statistics only from an authenticated server authority. ## Frequently asked questions ### Do original Steam owners need to create a revival account? No. A successfully validated retail Steam session resolves directly to a Steam-backed revival player record. ### Why not use Steam Spacewar AppID 480 for identity? Spacewar is Valve’s SDK example and proves access to the example AppID, not ownership of Ace of Spades. Original-owner validation must use an authorized path for the original game AppID. ### Can guests choose any nickname? Guests receive a server-generated Guest-XXXXXXXX name. This avoids impersonation and collisions while keeping registration optional. ### Are recovery codes emailed? No email is collected. The code is shown once and must be stored offline by the player. ## Related reading - [A master server for reconnecting the community](https://aosplay.net/master-server) ([Markdown](https://aosplay.net/docs/master-server.md)) - [Inside the Ace of Spades protocol 168](https://aosplay.net/protocol-168) ([Markdown](https://aosplay.net/docs/protocol-168.md)) - [Ace of Spades Revival Privacy Notes](https://aosplay.net/privacy) ([Markdown](https://aosplay.net/docs/privacy.md)) --- Source: [Ace of Spades Revival Player Identity](https://aosplay.net/account) Maintained by Ace of Spades Revival contributors.