0
votes

I would like to create an app (which will be public) that would send and receive some data in real-time to/from a server. Because for this particular use case the PUB/SUB pattern fits naturally, I was thinking about using the MQTT protocol with TLS. What are some best practices for securing access in such cases?

  • Would it be safe to only have one user with password for the mobile apps registered in the broker (like Mosquitto or RabbitMQ) and use ACLs for limiting client by ID for topics and store these secrets in the mobile apps? If not, what would be a suitable solution? (If using individual user in broker for each app account wouldn't it be a performance issue, given the potential big number of users?)
  • Are there any other schemes for allowing secure access from the mobile app to the broker?
2
If you are open to use cloud services. Then Google and AWS both have there own services for this use case. You dont have to worry about your own implementation and maintenance, but ofcourse you have to pay for per amount of use.Hsn
@Hsn what services specifically do you mean?Victor Dodon
For example: Google Cloud Platform Offers Cloud Pub/Sub and Cloud IoT core .. cloud.google.com/pubsub/docs/overviewHsn

2 Answers

1
votes

No, a single username/password is a REALLY bad idea. (All it takes is somebody to disassemble the app and the username/password are compromised and anybody can impersonate anybody else). Also linking clientIds to users probably means users can only have a single device.

Having a user sign in with a username/password should have minimal impact on performance as it will only be checked at connection time.

It also means you can revoke the username/password of a single user and not have to ship a new version of the app.

An alternative to username/password is to issue a certificate to user for them to authenticate with the broker. The CN from the certificate can be used to identify the user.

0
votes

If you use EMQ X MQTT Broker, the application can send messages to the application server through an HTTP request, the application server will authenticate, record, check, and then invoke REST API of EMQ X Broker to publish the message for the application agent.

The application can be sent only after it has passed the verification, and the sending operation history can be recorded

enter image description here