Securing your account

Your hosting account holds your websites, your mail and your data. This page covers what you can set up to protect it, in the order it is worth doing: a passkey, then recovery codes, then the rest.

Everything below lives in the panel under My account — you will find it under your own name at the bottom left of the menu. (Until 0.17.14 that place was called "Settings"; the word now belongs to the platform's settings, see Platform settings.)

A passkey: the single best thing you can do

A passkey is a key that lives in your phone, laptop or hardware token. You use it with your fingerprint, your face or your device PIN. There is nothing to remember and nothing to type — which is exactly why it is safe: a fake website cannot talk you out of your passkey, because the key only works on the address it was made for.

1. Go to My account → Passkeys.
2. Click Add passkey and follow what your browser asks.
3. Give it a name you will recognise ("iPhone", "work laptop").

Three things worth knowing:

• A passkey belongs to one address. If you sign in both on panel1.corecp.dev and on your reseller's own address, you register a passkey on each. That is not an omission; it is the property that makes a passkey impossible to phish.
• Once you have one here, it is required here. A code from an authenticator app is refused on this address afterwards. On an address where you have no passkey yet, nothing changes.
• Register two if you can — your phone and your laptop. Losing one device then stops being an event.

Recovery codes: the safety net

With your first passkey you get ten recovery codes. You see them once. Keep them out of your browser: printed in a drawer, or in your password manager.

Each code works once and stands in for your passkey at sign-in. Lost the sheet, or think somebody has seen it? Ask for a new set under My account → Sign-in & security — that makes the old sheet worthless immediately.

If you lose your devices and your codes, your hosting provider is the only way back in. See "For administrators" below; that is an operation on the server, not a button on a website.

Two-step verification with an app

If you have no passkey (yet), protect your account with an authenticator app: you scan a QR code and then enter a six-digit code when you sign in. That is clearly better than a password alone, and clearly weaker than a passkey — a code is something you can be talked into giving to the wrong website.

While you have no passkey, the panel shows a standing notice asking you to register one. It disappears by itself the moment you do.

Turning it off

Since 0.17.14 My account → Two-factor authentication also has a button to turn it off again. There are two thresholds in front of it:

1. A confirmation. The panel says what will happen — you will sign in with your password alone, and your recovery codes stop working — and the button in that dialog says Turn off, not Yes.
2. A fresh code. Even though you are already signed in: removing your second factor is the one thing you can do to your own account that makes it weaker, so the panel asks you to prove once more that it is you. Changing your password deliberately does not get that extra question — that makes your account stronger, not weaker.

If you are an administrator or a server administrator, you cannot. Those roles must keep two-factor authentication on; the button is not drawn and the screen says why. Going straight to the API does not help either: the server refuses it whatever the screen shows.

Your password

One password belongs to your email address, not to an account or a hosting provider. If you work with two providers who both run CoreCP, that is the same password — but what you see on each address stays strictly separate.

When you set a new password the panel looks at two things, and at nothing else:

• Its length. At least 15 characters for an ordinary account, 20 for administrators. No rules about capitals, digits or punctuation, and no forced renewal every so many months: that pushes people towards Summer2026! and is exactly what the standard (NIST SP 800-63B rev.4) advises against. Length is what counts.
• Whether it has already leaked. The panel checks whether your new password appears in known breaches. If it does, it is refused — that is not a judgement about how complicated it is, but about whether it is already public. Nothing about your password leaves your hosting environment to do it: five characters of a computed fingerprint go out, and the comparison happens here. If that service is down for a moment your password is simply accepted; somebody else's outage must not stop you.

What exactly is enforced can differ per platform: your hosting provider sets the minimum length. If your password is older and shorter than a new minimum it keeps working — the rule only applies when you change it.

Mistype it and the wait gets a little longer

After one mistyped password you wait a second before the panel looks at the next attempt; then two, then four, then eight, up to half a minute. For you that is a pause you barely notice. For a program trying passwords it is the difference between thousands of attempts a minute and a handful. Get it wrong several times in a row and the account locks outright afterwards — for how long is your hosting provider's setting, and it is never forever. The same wait applies to the code from your app and to a recovery code.

The screen says the same thing throughout: that email address and password do not match. That is deliberate — if it said "wait another eight seconds", anyone reading it would know an account with that address exists.

We tell you when something about your login changes

If you change your password, or switch two-step verification off, you get an e-mail about it — even if you switched every other notification off. That is deliberate: if it was not you, that message is the first you hear of it, and you can change your password and end your sessions straight away.

Messages about your security therefore cannot be switched off. On My account → Notifications you will see that row with a padlock beside it; every other group you are free to silence. My account also says straight away how many groups you have silenced, so "I never hear anything" has an answer. See Setting your notifications and e-mail.

That choice belongs to you and not to your browser: silence something on your laptop and it is silent on your phone as well.

We also tell you when somebody signs in from a new place

If somebody signs in to your account from a network it has never been signed in to from before, you get an e-mail about it: when it was, which browser it was and from which address. If that was you — a new internet connection, a hotel's wifi, a phone away from home — there is nothing to do. If it was not, this is the message you change your password on and end everything on My account → Sessions.

Three things worth explaining, because they are why the message sometimes comes and sometimes does not:

• It is about the network, not the exact address. Many internet connections are handed a different IP address by the same provider every few days. If the panel watched the address you would get a warning about your own living room twice a week — and a notice that always arrives is one nobody reads any more. So the panel remembers the block the address falls in.
• The very first time you get nothing. On a brand-new account every place is new, so the message would mean nothing. From the second different place onwards you do get it.
• Half a sign-in does not count. Somebody who only got your password right and could not produce a second step has not signed in — that goes in the log and not in your inbox.

This message belongs to the security group too, so it cannot be switched off. A place nobody has signed in from for a year is forgotten again.

Active sessions

My account → Sessions lists every device you are currently signed in on: which browser and operating system, from which IP address, when that session started and when it last did anything. The session you are looking at it with is marked.

Do not recognise one? Press End. That browser's next action lands on the sign-in screen — not a minute later, immediately. Your own session deliberately has no button: ending it is signing out, and there is a menu item for that.

Two things the panel deliberately does not do:

• It does not ask you to confirm with your passkey first. Signing yourself out of a laptop you left at a customer's office is the most security-raising thing you can do, and an extra question in front of it is a question people dismiss at three in the morning.
• There is no token or key in the list. Everything you see is descriptive; there is nothing anybody could reuse.

Changing your password ends all your other sessions anyway — that stays the fastest route if you distrust something completely.

Administrators are signed out sooner than everybody else. An administrator's session lasts a day by default, even if you use it all day long; for everybody else that is a week. This is not a penalty but arithmetic: an administrator account can restart servers, look inside every account and sign in as somebody else, and a laptop that went missing yesterday must not still reach that today. You notice it as signing in once at the start of your day. If somebody is made an administrator while already signed in, the shorter limit applies at once to the session they already had.

When your hosting provider looks inside your account

Your provider or reseller can, when support calls for it, sign in as you. That is visible and bounded:

• a banner at the top of the screen says who is looking, with one button to end that session;
• such a session lasts at most an hour and never extends itself;
• there are things it may not do: change your password, your email address, your two-step verification or your passkeys, reveal secrets, touch billing, or give other people access;
• everything that happens is written to the log — under your name and under the name of the person who was looking.

This is not something you approve case by case. If you want to know whether it happened, look at your account's activity view.

For administrators

Three more things belong to this subject on the panel itself.

Not everybody may sign in as a customer. It is an explicit right per person, off by default:

ssh root@panel1.corecp.dev
corecp-panel admin impersonation list
corecp-panel admin impersonation allow support@example.com
corecp-panel admin impersonation deny  support@example.com

Heavy operations ask for a fresh key. Fleet rollouts, join tokens, role and administrator changes, API keys and branding require a factor you proved in the last ten minutes. The panel asks by itself; there is nothing to configure.

The asking is the same everywhere in the panel: a Confirm who you are dialog appears, you type your code, and the operation carries on by itself — nothing has to be filled in again. Dismiss the dialog and nothing happens: the screen is exactly as it was, and there is no error message, because nothing went wrong. On screens that ask often it is said in advance: "You will be asked to confirm who you are as soon as you save something here."

One exception since this round: editing your own group's branding no longer asks. The platform's own branding — what everybody who has set nothing falls back to — still does.

Taking an address off the IP allowlist asks first, and the answer stays in that window. Under Settings → Platform security every address carries a Remove; the window that opens names what you lose, and it closes only once the server has done it. If the server refuses — because it would lock you out, for instance — the window stays up with the reason in it, instead of closing and leaving the message on the page behind it.

Break-glass runs on the server, never over the web. If you have locked yourself out with the IP allowlist, or an administrator has lost every factor:

ssh root@panel1.corecp.dev
corecp-panel admin unlock-ip 203.0.113.10/32      # let this address back in
corecp-panel admin disable-allowlist              # turn the list off entirely
corecp-panel admin reset-2fa admin@example.com    # remove every factor this person has

reset-2fa removes the app enrolment, the passkeys, the recovery codes and the sessions. That is deliberately all of it: half a reset is how somebody stays locked out. Each of these writes an audit row marked for paging, so it is never something that happens quietly.

Filtering the audit log, and linking to it

The Audit log page lists every action anybody took in your environment. The selector at the top right filters by outcome: everything, succeeded, denied or failed. Since round 2's final pass that choice also lives in the web address, which is more useful than it sounds:

• /audit?result=error — only what went wrong;
• /audit?result=denied — only what was refused (somebody tried something they had no right to);
• /audit — everything.

You can bookmark such an address or send it to somebody; they see the same selection. The dashboard uses it too: "104 tasks failed across the fleet" now takes you to exactly those rows instead of to the whole log.

The same thing from a terminal:

ssh panel1.corecp.dev 'corecp-panel audit list --result error --limit 20'

When a filter is on, the page says so with a label at the top and a button to take it off. A list quietly showing part of the truth is worse than no filter.

Searching the log, and clicking through to what happened

Since round 2b the search box above the log searches the whole log on the server, not only the rows your browser had already fetched. You search the technical name of the operation (mailbox.create), who did it, what it was done to, and the reason a refusal gives. Under the table it says how many rows match in total — on a busy log it says 10000+, because the panel stopped counting and narrowing the search is faster than waiting.

More importantly: every row now points somewhere. The Target column takes you to the account, the server or the plan the operation was about. If it was about a mailbox or a website you land on the search screen for that name — that screen knows which customer it belongs to, and it is the step you would otherwise take by hand with copy and paste. Rows with nothing to point at stay plain text; a link that ends on an error page is worse than no link.

# the same over the API: the counter is a header, the body stays a list
curl -si -b cookies.txt 'https://panel1.corecp.dev/api/v1/audit?limit=50&q=mailbox' \
  | grep -i '^x-corecp-total'

How searching, sorting and loading more work in every list is in Working with long lists.

The limit on outgoing mail is part of this

A website with a security hole sends thousands of messages before anybody notices, and what that costs is not the messages — it is the whole server ending up on a blocklist, so that your ordinary mail stops arriving anywhere.

So there is a ceiling: 100 messages an hour per mailbox, 500 per account. Nothing is refused; mail over the limit is held and delivered later, and your mail program retries by itself. Mail your website sends with PHP counts against the same ceiling, because that is exactly the traffic a compromised site produces.

If a mailbox of yours reaches its limit, you get one message about it that day — and that is worth reading, because a mailbox that suddenly wants to send five hundred messages an hour is usually a password somebody else has.

The buttons that let you in without a password

Webmail and phpMyAdmin open a new tab in which you are already signed in. That can feel like a back door, so here is exactly what happens.

• The panel never passes a password on. It asks the server for a single-use pass and forwards that to the tab. Nothing else travels with it.
• The pass is good for one use and ninety seconds. Refresh the tab and you get "that sign-in link has already been used" — that is by design.
• By default it only works from the network you were on when you clicked. Your administrator can make that stricter or looser.
• What it lets you in with is a key that opens one thing: for webmail only that one mailbox (and it does not work as a password in a mail client), for phpMyAdmin a temporary database login that may only touch the database you opened and is cleaned up afterwards.
• Every pass issued and every pass used is written to the server's log, so afterwards it is visible who went in where, and when.

Did somebody other than you see such a link? Do nothing: it is almost certainly already used or expired. Do report it to your hosting provider — they can look it up in the log.

See also

• Setting your notifications and e-mail
• Signing in, switching and finding your way
• Giving somebody access

Who may move an IP address

Replacing a server's IP address is reserved for a server admin: it touches every customer on that machine at once. A reseller can give one of their own customers an address of their own — it counts against their package allowance — but not a customer belonging to somebody else.

A server's management address, the one the server itself is reached on, cannot be replaced from the panel at all. The agent and the server certificate hang off it, so that happens on the machine itself. See Replacing an IP address.