Security Policy

Tagged on #feature, #Security,

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.