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 is not allowing wrong password and is sending an email message to registered users when
4invalid credentials are used within a
- 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.
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.
t6 on Saas is hosting data in Europe. And 2 alternatives are available to bypass this behaviour :
- POSTing your Datapoints using
save: falsein 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.