An overview of Rehive's architecture and infrastructure with respect to security

Michail Brynard avatar
Written by Michail Brynard
Updated over a week ago

Software architecture

  • Credential management

    • Rehive only ever stores cryptographic hashes of user passwords.

    • Passwords are hashed using the Argon2 algorithm which is recommended by OWASP as a modern, secure and flexible algorithm.

  • SQL injection protection

    • Rehive database queries are constructed using query parameterization. A query’s SQL code is defined separately from the query’s parameters. Since parameters may be user-provided and therefore unsafe, they are escaped by the underlying database driver.

  • Cross site request forgery (CSRF) protection

    • Rehive Platform supports both cookie-based Authentication and bearer token authentication.

    • Bearer token authentication is not susceptible to CSRF

    • Rehive’s cookie-based Authentication has built-in protection against most types of CSRF attacks provided it is used correctly.

  • Cross site scripting (XSS) protection

    • Rehive’s frontend apps escape any values received from external sources or user input before rendering them. Everything is converted to a string before being rendered. This helps prevent XSS (cross-site-scripting) attacks.

    • We only use trusted dependencies that are reviewed before use.


  • Networking

    • VPC Network with a firewall blocking all external traffic except for TCP traffic to our load balancer.

    • For increased security, we are running on private Kubernetes clusters where none of the nodes have public IP addresses.

      • All outgoing requests are routed via a NAT Gateway.

      • Deployments are managed via a bastion proxy.

      • This provides a third layer of security. Rather than being only protected by a firewall, our servers are completely cut off from the public internet.

  • Database

    • All data is automatically encrypted prior to being written to disk. Keys and encryption policies are managed in the same keystore as Google’s production services.

  • Access Control

    • Actively managed Role based access control for the Rehive team based on least privilege service accounts.

    • Rehive team members are required to use strong passwords and 2FA.

    • Only dedicated admin accounts that are secured by hardware security keys via Google Advanced Protection have owner level access to our infrastructure.

  • SSL

    • Rehive uses the latest version of the TLS protocol (TLS 1.3) for improved security and performance. Only connections that use TLS 1.2 or newer are accepted.

    • A+ Qualys SSL Labs Rating (Strong protocol, cipher and key-exchange support)

  • Virtual Machines

    • Automated regular Kubernetes version updates via GKE with automatic security patches from Google.

    • Underlying virtual machines are on Google Cloud which complies with ISO 27001, ISO 27017, ISO 27018, SOC 1, SOC 2, SOC 3 and many other certification standards.

  • Web Application Firewall

    • Protection against malicious attacks that aim to exploit vulnerabilities including SQLi, XSS via the OWASP Core Ruleset. Additional protection against zero-day vulnerabilities, via Cloudflare’s Managed Ruleset.

  • DDOS Protection

    • Powered by Cloudflare Enterprise, unmetered DDoS Mitigation, dedicated bandwidth.

    • Sub-second threat detection, mitigates most attacks in under 3 seconds

Did this answer your question?