Security policy - mathcoll/t6 GitHub Wiki

Various level of security

  • JWT and signed token (Token lifetime can be setup in configuration file, but suggested to be short);
  • POSTing your Datapoints timeseries allows signed payloads (with a shared secret) to check and verify sender;
  • POSTing your Datapoints timeseries allows encrypted payloads (aes-256-cbc only yet; with a shared secret, no public key yet);
  • POSTing your Datapoints timeseries allows both signed + encrypted payloads;
  • Optionally, signature and/or encryption can be required from a Flow;
  • Using aes-256-cbc Preprocessor will allows to store encrypted data in timeseries; but prevent you from Exploratory Data Analysis as t6 wouldn't be able to read your data :-)
  • Rule based events can send data to Mqtt using encryption;
  • User passwords are bcrypt-hashed in database; at least not in clear;
  • User passwords recovery process is secured, but still can be improved when the User set it's own password and Post data;
  • t6 is using multiple private certificates to run DKIM on email sending, Firebase FCM certificate;

Authentification process

  • Authentification process is not allowing wrong password and is sending an email message to registered users when 4 invalid credentials are used within a 1 hour window.
  • Please note that during authentication process, the user IP address (v4 and/or v6) can be logged on the user account for sattistic purpose.
  • Authentication in t6 is available in 3 modes:
    • a matching username+passwords for credentials;
    • a valid Key+Secret temporary and revokable token;
    • or a refresh token process.

All of these modes generates a signed JWT from the server and can be used fo a limited time.

Session duration

Sessions on t6 is using JWT short life Bearer tokens. Session last 5 minutes before token expires itself. Additionally, during authentication process a refreshToken is provided by t6 (this token last 24hours) giving the ability to refresh the token.

Data hosting

t6 on Saas is hosting data in Europe. And 2 alternatives are available to bypass this behaviour :

  • POSTing your Datapoints using save: false in the payload AND customizing the InfluxData Cloud Storage so that you can have a different data location external to t6
  • Installing your own t6 wherever you wants using this Github repository

CWE - Common Weakness Enumeration

t6 tend to follow Common Weakness Enumeration list. Here are the specific declarative list of mitigation efforts completed on t6:

  • The HTTP header "x-powered-by" is disabled in the responses
  • CWE-223 CWE-778 All authentication activities (successful or not) are being logged, at any level of debugging
  • CWE-223 CWE-778 All administrative activities (successful or not) are being logged, at any level of debugging
  • CWE-272 CWE-284 All new requests (not login users) have the least privilege possible.
  • CWE-312 CWE-319 The passwords, keys or certificates are not stored in clear files.
  • CWE-521 The users are forced to enter a strong password. :warn: partially completed, only frontend.
  • CWE-523 CWE-311 WE-319 All routes which transmit sensitive info use SSL.
  • CWE-778 All critical errors being logged, at any level of debugging.
  • CWE-778 Different levels of debugging are supported.