12

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.

  • Can you tell us how you think a device could do 2FA since it is one device? – Goufalite Dec 30 '16 at 19:26
  • @Goufalite For example when I install a new device, I have to provide a key manually (by an RFID tag for example) which will be used during authentication. As for software 2FA, I do not know if somekind of service could be set up in my home from which new devices could request soft tokens, something like a private key server. – Bence Kaulics Dec 30 '16 at 19:31
8

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...

| improve this answer | |
  • @tim3in sorry for the late response. After all this was an answer given 2,5 years ago... maybe things have changed and this was just a general architecture proposal. Did you do a POC with your solution? – Goufalite Jul 17 '19 at 9:16
  • I have planned it. Will you be able to review it? – tim3in Jul 17 '19 at 10:03
7

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.

| improve this answer | |
5

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.

| improve this answer | |
4

To achieve 2FA in MQTT network I have created following services for authentication which are connected to Broker.

  1. ID verifier
  2. Token Generator
  3. 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 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.

| improve this answer | |
  • 3
    How is it secured that only the correct client gets the token? – Helmar Jun 27 '19 at 18:28
  • @Helmar using the unique clientID and separate topic to store token for each client which is predefined at registration of device. The client actually subscribe to this topic. When it republish the token for check, it adds its id with token data so the verifier knows that which client has published this token. clientid may be protected using Secure Element at device side after registering the same id at server in the database. – tim3in Jun 28 '19 at 9:31
  • @Helmar would you please like to add your comment to this? I would appreciate views from everybody on my solution. – tim3in Jun 28 '19 at 9:41
  • 2
    yes, but what is to stop me subscribing to '#' to see all the token responses – hardillb Jun 28 '19 at 10:31
  • @hardillb topics that have token responses are locked as Goufalite mentioned. So only previliged device can see. At registration phase devices are bind to specific topics and each device has assigned separate topics for token responses. – tim3in Jun 28 '19 at 12:14

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.