Passwords are hashed, never stored
The panel keeps a bcrypt hash and nothing else. Nobody here can read your password - which is the same reason nobody here can tell you what it was. A reset is the only way back, and that is the point.
Security
RE:NODE writes its own panel rather than licensing one, so the security of this place is something we built and can describe rather than a feature list somebody else sold us. This page is what is in it - including the parts that are limits rather than features.
Everything that decides whether a request is really you.
The panel keeps a bcrypt hash and nothing else. Nobody here can read your password - which is the same reason nobody here can tell you what it was. A reset is the only way back, and that is the point.
Time-based codes from any authenticator app, with single-use recovery codes issued the moment you turn it on. Keep those codes somewhere that is not the phone: they are what gets you back in when the phone is gone.
Login, registration and password reset are rate limited per address and sit behind a captcha. Guessing a password stops being a thing worth trying long before it starts working.
Your account page lists every session that is open right now, where it is being used from and when it was last active, and lets you end the ones you do not recognise. The cookies themselves are encrypted, unreadable to JavaScript and not sent from other sites.
What a request goes through before it reaches anything of yours.
Plain HTTP is redirected rather than served, and certificates are issued and renewed automatically - so an expired certificate is not something that can quietly happen on a Sunday.
A request that changes something and did not come from a page we served is rejected. Another site cannot act as you in a tab you left open.
Most traffic that finds a panel is not looking for it: it walks the internet asking every host for credential files and source trees that do not exist here. Those requests are recognised on sight, the address behind them stops being answered, and it stays blocked for longer each time it comes back. Every refusal is written to a log an operator actually reads.
fail2ban sits in front of the application, so the traffic that is clearly not a customer never costs a PHP process at all.
One customer's server is not a folder inside another's.
Each server runs in its own container with its own filesystem and its own memory, CPU and disk ceilings. A neighbour cannot read your files, and a neighbour having a busy night cannot spend your resources.
Admin passwords, RCON passwords and database users are generated for your server rather than shared across a plan, and they are shown to you rather than to anybody else.
A key can be restricted to a list of addresses, which makes a leaked key useless from anywhere else. Keys are stored encrypted and shown once, when they are created.
Give somebody the console without the files, or backups without billing. Every action is attributed to the account that took it in the server's own activity log, so "who restarted it" has an answer.
Insurance that is not sitting on the same disk as the thing it insures.
The database and the runtime data are dumped every night. The dump is taken without stalling the panel behind a lock, the database password never appears on a command line where other processes could read it, and two runs cannot overlap and corrupt each other.
The panel, the customer volumes and the on-machine backups share one storage pool - so a pool failure would take production and its insurance together. Everything is pulled down to separate hardware as well.
Each copy is checked for archive integrity and, for a database dump, for the completion trailer that is only written when the dump actually finished. A backup nobody has verified is a guess.
Copies are pruned on a schedule instead of kept forever. Backups that grow until they take the panel down with them are a failure mode we would rather not invent.
In order, from the moment you press a button in the panel.
The connection is encrypted before a single byte of the request is sent. Plain HTTP gets a redirect and nothing else.
The address is weighed against what it has been doing. Requests that have already identified themselves as hostile end here, with a 404 that tells them nothing.
The session cookie is decrypted and the CSRF token checked - so the request is both from you and from a page we served you.
Only then is the action checked against what that account is allowed to do on that specific server, and written to that server's activity log.
The part of a security page that is usually missing.
Country lookups are answered from a table on our own machine. Resolving an address through a third-party service would mean telling somebody else about our visitors, one request at a time.
We count what gets read so we know which guides are worth writing. We do not keep who read them.
That is what hashing means. And if two-factor is on and the recovery codes are gone as well, the account cannot be handed back to anybody - including to you. Keep the codes.
Arma 3, DayZ, Project Zomboid and 7 Days to Die cannot be installed anonymously: the installer signs in to Steam as you, and the server needs those details again on every update. Use an account kept for servers, never your main one. Each of those game pages says so before you buy, not after.
If you think you have found a vulnerability, tell us before you tell anyone else and we will fix it. A report about a real problem is worth more to us than it is to anybody you could sell it to.
Contact us