How we protect sensitive credentials

Running infrastructure for you sometimes means handling sensitive access details, such as server root passwords, mailbox passwords and credentials for migrations. We design every one of these flows so secrets are stored encrypted, shown only on deliberate request, and never exposed where they do not need to be.

Your card details

Card numbers and security codes are entered directly into our payment processor's secure fields and never pass through or stay on YallowHost's servers. We keep only a token plus the card brand, last four digits and expiry date. See Saved cards and automatic renewals.

Passwords for your services

• Hosting: the hosting service page never displays your control panel password. Where one-click sign-in is available, you do not need it at all.
• Cloud servers and mailboxes: the root password and mailbox passwords stay hidden until you choose Reveal on the page. Reveals are only available to the account owner, are rate-limited and are recorded.

Credentials you share with us

Migration requests and management support have dedicated secure forms for access details.

• Migration credentials are encrypted when stored and are not shown back on your request page.
• Only staff with the relevant permission can view shared access details, and every view is recorded.
• Migration credentials can be purged from a request when the work is finished.

Please use these forms rather than tickets or email. Messages in tickets are not a suitable place for secrets.

Access logging

Sensitive actions are recorded in a security log: revealing a server or mailbox password, staff viewing shared credentials, and file uploads, downloads and share-link downloads. The log records who performed the action, what it was, when, and the IP address and browser used. It never stores the secret itself.

Identity documents and files

Identity verification documents and files in your Files area are kept in private storage and are not publicly accessible. Files are only shared when you create a share link, which you can protect with a password, limit by expiry or downloads, and revoke at any time.

Sharing access safely: best practices

• Create a temporary user or password for the task instead of sharing your main credentials, and remove it afterwards.
• Grant the minimum access needed. For example, share SFTP access to one site rather than a full reseller login.
• Change shared passwords once the work is complete.
• Prefer SSH keys over passwords for server access; see Connecting to your server over SSH.

If you believe a credential has been exposed, change it immediately and open a High priority ticket.