Network Module Support for Digest Passwords

[belias]

I use the ISY to integrate with various IP cameras to control all sorts of things.  In the past, I have used basic authentication (since they operate on secure networks).  However, lately the camera manufacturers are beginning to require digest authentication.  Is it possible for the network module to support this?

 

 

Thanks.

 

- Brian

[MWareman]

Specifically, RFC2617 ( http://tools.ietf.org/html/rfc2617).

 

While we are at it, how about oAuth - for talking to APIs that need it (looking at you Twitter!)

[builderb]

I also would like this, but I don't think it's in the cards right now.

[Michel Kohanim]

Hello everyone,

 

Unfortunately this is brand new and, based on everything else we have on our plate, it does not look likely.

 

This said, can anyone of you guys try regular tcp (if it's not ssl) and let me know if that works? i.e. you make your own headers and body and everything else.

 

With kind regards,

Michel

[belias]

Hmm... I was under the impression that digest authentication required 2-way communication between the device and the initiator (ISY).  I'm not sure how to try this with the network module.

 

I am new to this, so if I'm missing something - my apologies.

 

 

Thanks.

 

- Brian

[MWareman]

Hmm... I was under the impression that digest authentication required 2-way communication between the device and the initiator (ISY). I'm not sure how to try this with the network module.

 

I am new to this, so if I'm missing something - my apologies.

 

 

Thanks.

 

- Brian

You are correct.

 

The server sends a nonce in response to the initial request, client uses the username and password in hashing the nonce and sends it back to the server in a second request. Server does the same thing internally and, sharing the knowledge of the password, the user can be authenticated and the password itself never had to transit the network. Its more 'secure' then basic because the authorization cannot be replayed - each initial request will get a unique nonce to work with. However, it carries a bad weakness - there is no protection for the session cookie, leaving the user vulnerable to session hijacking. Its certainly not the panacea to securing a service - SSL is the correct answer to this.

 

ISY lacks the ability to do anything with any data received in response to the network request. There is no static 'authorization' header you can add, since the 'correct' header is dependent on the nonce received at the start of the connection.

 

Michael.

[Michel Kohanim]

Hi Michael, 

 

Thanks so very much for the details. I was not thinking clearly. We can definitely consider this feature with our next revisions. Just need to know how important it is.

 

With kind regards,

Michel

[builderb]

I'm no expert, but my understanding is that the Basic authorization available in the Network Module is essentially the same as sending your password in plaintext.

 

In today's security-conscious world, I'd hope some more secure methods of communication with other devices and services would be made available. My assumption is that most IoT stuff we all want to connect to will be ramping up their security too, so without effective authorization protocols available in the ISY, we won't be able to connect with them as that happens.

 

As a 'for instance', as I have mentioned before, I'm transitioning from an Indigo installation to the ISY, but I'm still using Indigo for some stuff. I can run scripts from Indigo that can control my ISY via REST. I can't go the other way without disabling some of the security in Indigo to allow it to accept a Basic authorization. I opted to find other workarounds (since it's likely temporary).

[Michel Kohanim]

builderb,

 

As MWareman suggested the best security is using https and not http. With https everything is encrypted including your passwords. Why not talk to Indigo using https?

 

With kind regards,

Michel

[builderb]

Likely because I don't know how yet! I can see if I can figure that out.

 

 

Sent from my iPad using Tapatalk

[belias]

Hello,

 

Just wanted to check on this and see if it is on the development roadmap?  A few of the big name IP camera manufacturers that I integrate with (Axis being one) have now started releasing firmware updates (and new camera models) that require digest authentication - which effectively stops my integration.  Any help would be greatly appreciated.

 

Thanks.

 

- Brian

[Michel Kohanim]

Hi Brian,

 

Unfortunately not as we have been buried in 5.x and just recently added support for ISY variables inside network resources. I suspect these cameras do not use https?

 

With kind regards,

Michel

[belias]

Hi Michel,

 

I had missed the addition of variables inside network resources - that is a huge benefit in my application - thank you!

 

As far as the cameras...they do support https, however in either case (http / https) they require a digest password authentication.  Unfortunately, I think this is going to become the norm for many network devices where security is a major concern (cameras, access control hardware, etc.).

 

For now if it could perhaps get a slot on the to-do list, I would greatly appreciate it.

 

Thanks,

 

- Brian

[Michel Kohanim]

Hi Brian,

 

Yes, 5.0 is going to be amazing!

 

Can you tell me which digest algorithms your cameras are supporting?

 

With kind regards,

Michel

[belias]

Hi Michel,

 

Apologies for the delay in getting back to you on this.  I reached out to the developer technical support for Axis cameras and they provided the following information for digest authentication - hopefully it's helpful.

 

- Their Apache implementation uses RFC 2617; they reference:  https://www.ietf.org/rfc/rfc2617.txt

 

- They also provide the following "typical example"

====
* client
GET /axis-cgi/motion/motiondata.cgi?group=0 HTTP/1.1
User-Agent: Wget/1.13.4 (linux-gnu)
Accept: */*
Host: 192.168.0.71
Connection: Keep-Alive

* axis camera
HTTP/1.1 401 Unauthorized
Date: Tue, 14 Apr 2015 10:56:48 GMT
Server: Apache/2.4.10 (Unix) OpenSSL/0.9.8zc
WWW-Authenticate: Digest realm="AXIS_ACCC8E372402", nonce="1Y5cFq0TBQA=eb9ce3dbc8657b4494b4ad98a0e4108004cbdca3", algorithm=MD5, qop="auth"
Content-Length: 381
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Content-Type: text/html; charset=iso-8859-1

*client

GET /axis-cgi/motion/motiondata.cgi?group=0 HTTP/1.1
User-Agent: Wget/1.13.4 (linux-gnu)
Accept: */*
Host: 192.168.0.71
Connection: Keep-Alive
Authorization: Digest username="root", realm="AXIS_ACCC8E372402", nonce="1Y5cFq0TBQA=eb9ce3dbc8657b4494b4ad98a0e4108004cbdca3", uri="/axis-cgi/motion/motiondata.cgi?group=0", response="33988477727c8138aa4070f3624d4156"

Thanks again for the effort with this - much appreciated.

 

 

- Brian

 

[Michel Kohanim]

Hi Brian,

 

Thank you. If you already know what should be sent to the camera, simply click on the Add Header and:

- For name put: WWW-Authenticate

- For value put: . So, in the example above, you can put:

Digest realm="AXIS_ACCC8E372402", nonce="1Y5cFq0TBQA=eb9ce3dbc8657b4494b4ad98a0e4108004cbdca3", algorithm=MD5, qop="auth"

 

The only problem might be the nonce. The issue I have is that MD5 is an obsolete hash algorithm. I am not sure why they are using it.

 

With kind regards,
Michel

[MWareman]

MD5 is (still) the standard for Digest authentication. The main issue is that the response has to be calculated from the nonce sent by the server - and this will be different for each initial connection. The ISY cannot calculate this. The authentication system allows the client to prove it has the correct password without having to actually send the password on the network. It was designed when SSL was still very expensive (in $$ and compute power) and the industry wanted a 'secure' logon that was 'secure' without ssl needed. Quite neat really. Its real flaw is that many implementations seem to feel ssl is not required, when it is still needed to secure the session against hijacking.

 

Digest authentication may be a little dated now, but many devices still use it. My feeling is that this and oAuth2 should be considered in addition to basic.

 

Michael.

[Michel Kohanim]

Hi Michael,

 

Unfortunately this requires a conversation with the resource which is not trivial.

 

With kind regards,

Michel

[MWareman]

Hi Michael,

 

Unfortunately this requires a conversation with the resource which is not trivial.

 

With kind regards,

Michel

I fully agree. Not a trivial thing to implement. I really hope more and more vendors start realizing that digest authentication is NOT a replacement for SSL support.