The following very interesting paper from DEFCON shows how vulnerable MQTT brokers can be if the designers are not carefully considering the various attack vectors that can be exploited in an IoT solution powered by MQTT.
The paper shows how one can find and access MQTT brokers on the Internet and perform actions such as open prison doors, change radiation levels, and so on. Your personal information may already be available via a public MQTT broker.
Since MQTT brokers listen on a port number, a simple port scanner can find the broker. The device search engine Shodan now includes searches for MQTT brokers. The paper goes into how to use Shodan to find public brokers and then uses commands that reveal every device connected to the broker.
In contrast, the SMQ IoT protocol (a pub/sub protocol similar to MQTT) has a very limited set of attack vectors compared to MQTT. You can completely hide the SMQ broker from automated tools such as Shodan and other port scanners. This is possible since an SMQ connection initially starts as HTTP(S) and a port scanner cannot see the difference between an SMQ broker and a standard web server. In addition, the URL to the broker can be private.
Since SMQ runs within an application server, no public debug API is necessary. SMQ provides an extended privilege API, but this API is only accessible to application code that runs on the application server and interacts directly with the SMQ broker.
SMQ provides hash based authentication, a feature required when not communicating over SSL. MQTT sends credentials in clear text. However, both protocols will be more secure when communication is protected by TLS. Note that TLS alone will not protect against many of the vulnerabilities mentioned in the paper. For this reason, system designers must have a good understanding of IoT security or the designers must seek help from experienced IoT security specialists by, for example, using the support line provided with commercial security products.