Skip to main content

Information security strategy / policies

Kubernetes​

All communication done with our kubernetes cluster is encrypted over TLS. We also encrypt and store all keys and secrets with Google, currently Google managed all our cluster permissions but we would like to investigate a possible move to Hashicorp Vault in future which can also do automated key rotation.

Letsencrypt​

All SSL certificates are generated by Cert manager which goes through our Google Load balancer.

Proxy an SSL certificate with K8​

An NGINX config can be added to the devops repo. An example of an implementation done for our Intercom help centre (help.reos.co.za) can be found here devops/kubernetes/services/intercom.

User information​

All user passwords are hashed with PBKDF2WithHmacSHA1

PBKDF2 Stands for Password-based-Key-Derivative-Function, a successor of PBKDF1 and is used to implement a pseudorandom function, such as a cryptographic hash, cipher, or HMAC to the input password or passphrase along with a salt value and repeats the process many times to produce a derived key, which can then be used as a cryptographic key in subsequent operations.

HMAC Stands for Keyed-Hash Message Authentication Code (HMAC) is a specific construction for calculating a message authentication code (MAC) involving a cryptographic hash function in combination with a secret cryptographic key. Any cryptographic hash function,may be used in the calculation of an HMAC; the resulting MAC algorithm is termed HMAC-MD5 or HMAC-SHA1 accordingly.

HMACSHA1 is a type of keyed hash algorithm that is constructed from the SHA1 hash function and used as an HMAC, or hash-based message authentication code. The HMAC process mixes a secret key with the message data, hashes the result with the hash function, mixes that hash value with the secret key again, and then applies the hash function a second time. The output hash is 160 bits in length.

The PBKDF2WithHmacSHA1 will produce a hash length of 160 bits.

JWT​

When a user logs in to the system they are issued an encrypted JWT token with an expiration set to 2 hours. We currently use http://pauldijou.fr/jwt-scala/ to encode and decode our JWT tokens.

TOTP​

We currently use time based OTP's to verify users when they first sign up. We would like to make use more of this in the future by giving users the ability to approve payments from e-mails and notifications we send them, as well as issuing temporary JWT claims for doing bulk payments.

Policies​

  • All keys are to be encrypted and stored with Google secrets.
  • No keys are to be stored in our code repositories.
  • Keep Kubernetes up to date to avoid security vulnerabilities.