Security

What we actually do

This page describes measures that are in place today. We hold no security certifications and we do not claim any.

• ·Passwords are stored only as bcrypt hashes. We never store or log them in plaintext and cannot recover them.
• ·Two-factor authentication (TOTP) is available on every account, and the TOTP secrets are encrypted at rest with Fernet (AES-128-CBC with HMAC-SHA256).
• ·Sessions use signed JWTs; sign-in with Google uses OAuth 2.0 with PKCE and server-side verification of the identity token.
• ·Traffic between your browser and BusyBee.Day is served over HTTPS.
• ·File attachments are stored in Cloudflare R2, which encrypts every object at rest with AES-256 and secures transfers with TLS.
• ·Application, database and cache servers are hosted with Hetzner Online GmbH in Finland, inside the EU.
• ·Sign-in tokens and keys for services connected to bots, and AI keys you add, are encrypted before they are stored.
• ·Bot computers are isolated cloud machines, one per project; bots cannot reach BusyBee.Day's internal network from them or through web fetching.
• ·Team access is controlled by six roles, and an activity log records who changed what.
• ·Backups are taken regularly so data can be restored after an incident.

What we are still improving

We would rather tell you this than let you assume otherwise. Our MongoDB deployment is MongoDB Community Edition, which does not offer native encryption at rest, so database contents rely on the security of the host rather than database-level encryption. Hardening the database connection and storage layer is on our roadmap. If this matters for your use case, ask us before you rely on BusyBee.Day for sensitive data.

Reporting a vulnerability

We do not run a paid bug bounty programme. We do want to hear about security problems: report them through busybee.day/contact with enough detail to reproduce the issue, and we will acknowledge it and keep you updated. Please give us a reasonable opportunity to fix it before disclosing it publicly.