Tag Info

I have software (Windows Server - a little different to 'things' but the principal is the same) that calls in every 24 hours - it sends back various meta data about itself : customer name (or unique ID) software version timestamp of call/request product type / id The web service parses out the data and inserts (or updates if the customer has an existing ...

You need a broker proxy, or a webserver... First of all, you absolutely need a authentication service somewhere connected to your broker to perform the 2FA using specific topics (/auth/RFID,...). It would then allow client to publish information (see below). The first problem I can see here is that anybody subscribed to this topic can read the information ...

The upcoming MQTT v5 specification adds support for the AUTH control packet, which allows challenge/response authentication. As MQTT v5 isn't yet finalised support may still change, but it seems reasonable to assume that AUTH will remain in some form or other and that 2FA could be added using it. You can see the current working drafts of the spec at the ...

You could, for example, make a request every X weeks/days/hours... to a server with the current version number of the software. You will after be able to use analytics to see the current percentage and number of devices updated.

Keep in mind, that when connecting the first time and trying to register a certificate with JIT you have to provide not only the device certificate but also the CA certificate you used to sign your device certificate (your CA in this case). You can combine the 2 certificates with cat deviceCert.crt caCert.crt > deviceAndCA.crt as explained here. OK, I'...

As per the specification, the connect message may optionally provide user name and a password. This is validated against a ACL saved somewhere on the broker. So, that is your first factor of authentication you could exploit. The CONNACK message from broker will respond if the authentication went through. To implement the second factor if authentication, the ...

To achieve 2FA in MQTT network I have created following services for authentication which are connected to Broker. ID verifier Token Generator Token Verifier When MQTT client connects to broker over SSL/TLS, it first publishes its own ID to device_id topic, the ID Verifier verifies that it is the authentic client and then Token Generator is invoked which ...

It's all about a smart synchronization policy You need a smart synchronization policy that works in tandem with your roll-out approach of your update. The most obvious point in time where the IoT device should sync its version is directly after the update. The rest of the sync schedule is highly dependent on the type of device. Is it always on and ...

Never let "anyone" add stuff via MQTT to a database ;) Once bad data gets into the database, any results from your analysis programs will be skewed at best, or down right wrong at worse. Any time you have MQTT traffic coming from "outside", you want to have a few things in place: DDoS protection so someone can't swamp your database, Topic Validation...is ...

There should be no need to use Authentication via HTTP first for MQTT devices. MQTT supports Authentication which can be linked to ACLs to control what topics a given user/device can publish/subscribe to. Authentication can be user/password at the MQTT protocol level or TLS certificate based the transport level. Most brokers support wildcard (and variable ...

Assuming you need to handle firmware updates (otherwise, you're insecure by default) then you will also need to sign the updates (and manage updates in a secure way). Otherwise, an attacker can simply present your device with a compromised update package. Clearly, if you do this, you make it impossible for the user to apply firmware updates in the same way, ...

Great question! Several things you should keep in mind. 1. Default passwords This is really basic, and you've probably already thought of it, but let me reiterate: default or easy passwords are deadly. When I asked this question, I learned that the way the Mirai worm works is simply to attack via default usernames and passwords. Whatever you do, do not ...

allow_anonymous false needs to be in the mosquitto.conf file not the acl file IIRC the logging is delayed because of a minor bug in some versions of mosquitto because you are not driving any other load through the broker

I've found this library useful to solve issues with authentication. If you encountered same issues on GSM modules with Arduino, it may help you as well: https://github.com/elementzonline/SIM800_MQTT

I ran into a similar problem with a different solution If you create a certificate using a default openssl.cnf, or some other mechanism that generates an SSL certificate such as PHP's openssl_csr_sign, make certain your generated certificate does not have the x509_extensions set to make a CA certificate. After three days of banging my head against the wall,...

If you do not want to bother with broker yourself and embed any authentication scheme inside it I have solution for you (non commercial, e.g. it is free): Per each instance of your small IoT platform you need to have separate flespi.io account(we call it customer). Your platform will have in configuration one flespi supertoken (for accessing flespi.io) and ...

The answer is more or less same if you have seen this question Should there be one device provisioning service for one IoT hub if it is associated with one tenant? Yes DPS isolates tenant configuration based on attestation mechanism. Let's say, if X509 certificate based attestation mechanism is used and there are 5 tenants. There will be single root CA for ...