Securing your Clouduxe account

Your Clouduxe account is a separate thing from your server, and it needs separate protection. Someone who takes the server has your data. Someone who takes the account can rebuild the server, reset its root password, power it off, change its protection rules, read your billing history, and open tickets as you.

Hardening the machine does nothing about that. This page is the account half.

Use a password that exists nowhere else

The panel refuses anything under 8 characters and recommends at least 12. Follow the recommendation, and add the part it cannot enforce: the password must not be one you have used anywhere else, ever.

Reused passwords are how most accounts are taken. The leak happens at some unrelated service, the address and password are tried in bulk against everything else, and your host is an obvious thing to try. A password manager solves this properly: generate a long random one, let the manager remember it, and never think about it again.

Security and 2FA has the change-password form, and one behaviour worth knowing now rather than later: changing your password does not end any other session. Devices that were already signed in stay signed in until you sign them out from the same page.

Turn on two-factor authentication

With 2FA on, a stolen password is not enough on its own. This is the single largest improvement available to your account, and it takes a few minutes.

Clouduxe 2FA is authenticator-app only. There are no SMS codes, no email codes, and no printable recovery codes, which makes one step non-negotiable: save the secret shown during enrolment into your password manager before you finish. That saved secret is how you set the account up again on a new phone. Without it, losing the device means opening a ticket to get back in.

Security and 2FA walks through enrolment, including why entering the secret by hand is preferable to scanning the QR code.

Check the two lists on that page occasionally

The same page shows every device with a session in the panel, and the last 10 sign-in attempts with their result, device, and address. Look at both now and then. A successful sign-in you cannot account for is the earliest warning you will get, and the fix is on the same screen: change the password, sign the other devices out, and confirm 2FA is on.

Protect the email address, because it resets everything

Every account recovery path leads to your inbox. Password resets arrive there, address verification arrives there, invoices arrive there. Whoever controls that mailbox can take the account without ever knowing your password, so it needs the same care as the account itself:

• A unique password on the mailbox, and 2FA on the mail provider.
• Check for forwarding rules and filters you did not create. Quietly forwarding or auto-archiving mail from your host is a standard move after a mailbox is compromised, precisely so that reset emails are never seen by you.
• Use an address you will still control in years. Not a work address you lose when you change jobs, and not an address on a domain that could lapse.
• Keep the address current. Changing the address you sign in with is a support request rather than a form, so choose deliberately and keep the mailbox alive.

Be careful who you grant delegate access to

Delegate access invites someone to help with your account under their own sign-in. It is the right tool for a business partner or a long-term administrator, and the wrong tool for a one-off favour. Three things to hold in mind before you send one:

• Grant the narrowest scope that works. Full account covers services, billing, and tickets. Specific services covers only what you tick.
• The scope cannot be edited afterwards. Changing it means removing the delegate and inviting them again.
• Removal is immediate and has no confirmation step, so it is always available to you, and a mis-click removes someone.

For "can you look at my server tonight", give access to the server rather than to the account: create them a user on the machine, or add their public key. That access is scoped to the box, is visible to you, and is removed by deleting a line in a file. See Securing a new server and Users and permissions.

Whatever you share, do not share your own sign-in. Any session signed in as you can reveal every credential stored in your Vault, which is exactly why one shared password is never only one password.

Recognising phishing that impersonates a host

Hosting customers are a good target because the pretexts write themselves: a failed payment, an expiring server, an abuse report, an unpaid invoice, a suspension in two hours. The message is urgent by design, because urgency is what stops people checking.

What genuine Clouduxe contact looks like: support conversations happen as tickets in the panel, and invoices and billing live in the panel. There is no live chat. So anyone who opens a conversation somewhere else, a direct message on Discord or Telegram, a phone call, a message from a "staff member" you did not contact, is not using a support channel that exists.

Treat any request for these as fraudulent, whoever it appears to come from

• Your account password. Nothing legitimate ever needs it, including support.
• A 2FA code, or the 2FA secret, or a photo of the QR code. Codes are phished in real time: a fake sign-in page collects the code from you and uses it within its 30-second window.
• A link from your email, such as a password reset or an email verification link, forwarded to someone else.
• Remote control of your computer, through screen sharing or a remote desktop tool, to "fix a billing problem".
• Payment outside the panel's own payment flow, especially by cryptocurrency, gift card, or a direct bank transfer to an account named in a message.
• Server root passwords or SSH keys, sent over chat.

Habits that defeat most of it

• Navigate, do not click. When a message says your invoice is overdue or your server is suspended, open the panel yourself by typing the address, and check. If it is real, it is visible there.
• Check the address bar before typing a password. Look at the domain carefully, including hyphens and lookalike characters. A convincing copy of a sign-in page takes minutes to build, and the domain is the part that cannot be copied.
• Slow down on urgency. Deadlines measured in hours are a technique. Nothing legitimate is lost by checking through the panel first.
• Verify by opening a ticket yourself. If a message might be genuine, open a ticket from inside the panel and ask. That thread is one you know is real, because you started it.

If you think your account has been accessed

Work through this in order, and do not wait for confirmation before starting.

1. Change your password, then sign the other devices out

   In that order. Both controls are on Security and 2FA. Changing the password alone leaves an intruder's session live, which is the mistake that lets them back in after you think you are done.

2. Turn 2FA on, or turn it off and on again

   If it was off, enable it now. If it was on and you suspect the secret was captured during a fake enrolment, disable and re-enrol so the old secret stops working, and save the new one.

3. Check the mailbox that resets your account

   Change its password, check its forwarding rules and filters, and end its other sessions too. An account recovered while the mailbox is still compromised is not recovered.

4. Look for changes that were left behind

   Check the delegate list for entries you did not invite, your email addresses for one you did not add, and your billing details for changes. These outlive a password change, and they are how access is kept.

5. Rotate what the account could reveal

   Anything stored in your Vault, and any server credential that was visible in the panel or sent to that mailbox. Assume it was read.

6. Open a ticket

   Tell support what happened and when you noticed. See Opening a ticket. If your server may also have been touched, work through What to do if your server is compromised in parallel, because a rebuild from the panel does not tell you the machine was clean before it.

Related