Protecting an MQTT Broker
Sy
employees (thats what I've heard).
How can you safe guard against someone else using your broker?
Nicholas O'Leary
MQTT has username/password support so you can ensure only
authenticated users connect.
Depending on the broker implementation, different users can then be a
authorised to perform different actions.
For example, some users may only be allowed to subscribe to certain
topics, whilst others with more privileges can publish to them as
well.
Use of SSL or running on a VPN can also be used to secure the network.
Cheers,
Nick
> --
> To learn more about MQTT please visit http://mqtt.org
>
> To post to this group, send email to mq...@googlegroups.com
> To unsubscribe from this group, send email to
> mqtt+uns...@googlegroups.com
>
> For more options, visit this group at
> http://groups.google.com/group/mqtt
DanAnderson
While we are on this topic...
It's common to have a "Security Considerations" section in protocol
standards that describes areas of concern related to security. i.e.,
the IETF templates.
In the next version, could something like this be added?
I'd like to see a "security consideration" added that suggests to
broker implementers that passwords should not be stored on the brokers
in clear text.
It's a relatively easy fix to salt/hash passwords and only store this
result in the password file and cryptographically secure libraries are
commonly available to do this in a wide variety of languages.
Storing passwords in clear text is widely considered a software
security weakness (http://cwe.mitre.org/data/definitions/257.html) and
may affect implementation in security conscious organizations and
industries.
Even if this is not directly an MQTT protocol problem - IMO, this
would be appropriate to mention in the specification because the
addition of the username/password feature requires storage of this
information.
Thanks
Dan
On Jan 26, 4:06 am, "Nicholas O'Leary" <nick.ole...@gmail.com> wrote:
> Hi Sy,
>
> MQTT has username/password support so you can ensure only
> authenticated users connect.
>
> Depending on the broker implementation, different users can then be a
> authorised to perform different actions.
> For example, some users may only be allowed to subscribe to certain
> topics, whilst others with more privileges can publish to them as
> well.
>
> Use of SSL or running on a VPN can also be used to secure the network.
>
> Cheers,
> Nick
>
>
>
>
>
>
>
>
> > The no.1 source of industrial sabotage comes from disgruntaled
> > employees (thats what I've heard).
>
> > How can you safe guard against someone else using your broker?
>
> > --
Hiram Chirino
Even if this is not directly an MQTT protocol problem - IMO, this
would be appropriate to mention in the specification because the
addition of the username/password feature requires storage of this
information.
Hiram Chirino
Software Fellow | FuseSource Corp.
chi...@fusesource.com | fusesource.com
skype: hiramchirino | twitter: @hiramchirino
blog: Hiram Chirino's Bit Mojo
Dan Anderson
True, but storing is storing.
Clear text passwords in LDAP or another DB (etc) isn't really any better.
Dan
DanAnderson
necessarily a file.
In case that wasn't clear. :)
Dan
On Jan 26, 10:45 am, Dan Anderson <dan-ander...@cox.net> wrote:
ka...@tweak.net.au
> Hi,
>
> While we are on this topic...
> I'd like to see a "security consideration" added that suggests to
> broker implementers that passwords should not be stored on the brokers
> in clear text.
> Storing passwords in clear text is widely considered a software
> security weakness (http://cwe.mitre.org/data/definitions/257.html) and
> may affect implementation in security conscious organizations and
> industries.
>
> Even if this is not directly an MQTT protocol problem - IMO, this
> would be appropriate to mention in the specification because the
> addition of the username/password feature requires storage of this
> information.
I think it would be more appropriate to remind people that the "username/password" fields in the MQTT
protocol are just bytes. They're even in sequential bytes. I don't really even think they should be
called username & password. They're simply two more fields that can be used (with clientid) to help
identify a connection. It's about as secure as telnet, in that it doesn't matter a jot how secure you
store the passwords on the broker, anyone listening to the traffic has the password.
Brokesr are free to _interpret_ the username and password fields as something else, but that's not
currently how anyone seems to talk about it.
Cheers,
Karl P
DanAnderson
On Jan 26, 11:50 am, ka...@tweak.net.au wrote:
> I think it would be more appropriate to remind people that the "username/password" fields in the MQTT
> protocol are just bytes. They're even in sequential bytes. I don't really even think they should be
> called username & password. They're simply two more fields that can be used (with clientid) to help
> identify a connection.
>currently how anyone seems to talk about it.
strings of bytes are the username and password - IMO, that's what they
are and brokers need to treat them as such (or it's no longer
technically MQTT). If you start using them as 128k of extra info -
you won;t be interoperable (which presumably is t he point to having a
spec in the first place).
>It's about as secure as telnet, in that it doesn't matter a jot how secure you
> store the passwords on the broker, anyone listening to the traffic has the password.
ssh tunnel, etc) - but it doesn't follow that they shouldn't be stored
properly.
I agree otherwise with your telnet analogy - any telnet client that
stored passwords in clear text would indeed be similarly vulnerable.
Dan
Roger Light
> It's about as secure as telnet, in that it doesn't matter a jot how secure you
> store the passwords on the broker, anyone listening to the traffic has the password.
I prefer to think of it as being as secure as http, for which the same
is true in many situations.
Cheers,
Roger
DanAnderson
This is true for "forms authentication" (credentials passed as POST
parameters - probably the most common - but done over SSL (hopefully))
and HTTP basic auth (base64 _encoded_ only).
It's less true for HTTP digest auth which has been around since the
90's.
I don't recall an HTTP server that would allow clear-text storage of
passwords for basic or digest. Not saying they didn't exist (all sorts
of bad ideas have existed), but I don't recall one.
"Forms authentication" is entirely outside of HTTP (It's just a
payload), but web application "best practices" (OWASP, SANS/Mitre Top
25) certainly preclude storing clear text passwords.
Dan