Protect your account, credentials and server access

Protect the two ways into your account

Your password signs you in; your username and recovery code can replace that password. Treat both as secrets with the same practical importance. Use a unique password and keep a complete recovery-code copy somewhere you can reach without relying entirely on the device used to sign in.

Standard signup does not collect email or telephone details, so account safety depends on keeping these credentials available and private. Do not send either credential through Contact. A support description should contain the account username, relevant references and the problem, without information that would let a reader sign in as you.

Use a simple sign-in routine

Sessions expire and may become invalid after recovery. If an action reports a session-verification or refresh error, refresh the account page first; sign in again if requested. Repeatedly pressing a payment or order button is not a useful way to repair authentication.

1. Open the Tungsto address you trust and check it before entering a password or recovery code.
2. Sign in from a device you control. Avoid leaving a funded account open in a shared browser profile.
3. Check the displayed username before placing an order, adding balance or issuing a server action.
4. Use Sign out when you finish on a device that other people can access. Closing a tab alone is not the same as signing out.
5. If a page asks you to sign in again, authenticate normally and reload the page before repeating a pending action.

Respond to suspected account exposure

1. Use account recovery from a trusted device with the current recovery code and a new unique password.
2. Save the replacement recovery code. Successful recovery revokes existing account sessions.
3. Review the ledger for unexpected balance changes and the Servers page for unexpected assignments or states.
4. Review any server whose access may have been affected. Account recovery does not automatically change the server operating-system credentials.
5. Record relevant account, order, ledger or action references and submit a security contact request if you need operator assistance.

Keep SSH access separate

The SSH & API keys page accepts an OpenSSH public key with a label. Only paste the public key, never its private counterpart. Saving a public key records it in the account; the order form separately accepts the public key to use for that deployment. Do not assume a saved key is automatically installed on every current or future server.

Keep control of the private key on your own device. The account page does not offer a complete key-removal or server-access audit flow. Removing an authorized key inside a server’s operating system is a separate administration task and should be performed carefully so you retain a working way in.

Understand API credentials before using them

The interface can create a key and display its secret once, but bearer-key authentication is not implemented by the current API. Protected requests use the signed-in session, and changes also require session verification. Do not treat the key scope selector as an active permission boundary for automation.

Keep key secrets private even while this compatibility is limited. There is no key revocation control in the current interface. For integration work, read the authentication guide before storing a key in a script or assuming it grants access. Prefer reviewing the actual result of an operation over relying only on a button’s success message.