How can I use 2FA (two factor authentication) when I connect a new device to the broker, if it is even possible?
Because it seems easier, the second factor can be a software solution first but I would welcome ideas on how to introduce hard tokens (RFID maybe).
It would make sense if the devices should authenticate only at the first connection and server would remember "old" clients.
The idea maybe unusual or unsuitable - if it is a bad idea, please give me the reasons why.
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 of that topic, but you can lock topics!
You can then tell (force) all your devices to publish information to /proxy/mytopic. With the clientId feature of mqtt, the auth service can check if the messages sent from this topic are from an authenticated device that used 2FA previously, and then publish its own message on behalf of the device to /proxyout/mytopic with the device's id in the payload.
The problem now is checking for devices that can recieve messages if they are authenticated, because, well, MQTT is all about mass publication. The auth service needs to have a list of authenticated devices and check if they are eligible for reception. Again, payload encryption and decryption device-side...
I think my solution is very overkill over MQTT capabilities. You should therefore use a socket or a web server...
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 OASIS MQTT committee documents page.
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 best way should be to send a custom connect message with the other factor. The CONNACK message in this case should refer to success or failure of the second factor of authentication. Therefore, the broker and client should implement custom messages over and above the specification.
To achieve 2FA in MQTT network I have created following services for authentication which are connected to Broker.
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 generates a token and publishes the token on locked topic device_token.
The client device gets this token and further publishes it to a topic verify_token. As soon as the topic is published on verify_token the token verifier compares the values at topic device_token and verify_token if it matches it add the device's id to verified device pool and allow the device publish data. This improves security because the only verified devices gets connected to the topics to publish data.
I have also used MQTT_KEEPALIVE configuration option to keep the client active when no data is being sent or received to keep the client device alive in device pool and prevent it from being verified again once it is added to device pool. however for security purpose I froce the device to 2FA every 24 hours.
