MQTT Broker with TLS and JWT

Question

We are currently working on a data-backup kinda project. We ship our own hardware to industrial customers. This hardware will then read out all related data the customer wants to backup and sends them to a cloud server using MQTT (Node.js Client and Mosca MQTT Broker).

Now my questions are:

• Is there a free TLS certificate that i can use for my MQTT connection? The only ones that i found require a domain name.
• To incease security, we are using JWT. We don't have any database though. The Token will be passed as an MQTT-Password argument. Is there a better alternative?

Answer 1

Is a self-signed TLS certificate bad practice even if the private cert is not publicly available? It will only be shipped embedded into our hardware and to our verified customers.

Of course it is bad practice (very bad practice). Get a certificate from a proper CA authority. Unless you want your company to be sued into the stone-age for a security breach.

Answer 2

• Is there a free TLS certificate that i can use for my MQTT connection? The only ones that i found require a domain name.

The certificate "certifies" that the information is provided by a specific entity, where the entity is defined as "a domain name".

Asking for a TLS certificate which doesn't back to a domain name is like asking for a certified check drawn on a company that doesn't have a name.

• To incease security, we are using JWT. We don't have any database though. The Token will be passed as an MQTT-Password argument. Is there a better alternative?

Yes, there is a better alternative. Have some sort of database (it can be a file system, it doesn't need to be a full-fledged SQL database) hold and manage the created tokens. Without a database to validate the tokens against the current expected values, any kind of token based security (JWT or otherwise) will be useless, as you can't determine if the token is currently valid.

Credential reuse (the replay of should-be-expired credentials) is a major security hole. All one needs to do is obtain the token, and then all future communications are accepted with the same credentials. This is closed by holding the tokens in a database, and expiring the tokens after some time by removing the tokens from the database. This means that any possible breach is limited to a shorter time span.

Without any kind of database, I can only guess that you might be permitting any access with an existing token, meaning that all your tokens are effectively valid forever, as they will be accepted if they exist. You need to possibly modify, and certainly validate, that expired tokens don't grant access to the controlled operations.