bTwix Posted January 3, 2013 Posted January 3, 2013 Living Room Stereo Off | Computer | AirTunes | 94.9Roku | Apple TV | XBOX Vol-Soft | Vol-Normal | Vol-Loud Lights-Normal | Lights-Soft | Lights-Off Kitchen Stereo Off | Computer | AirTunes | 94.9Bedroom Stereo Off | Computer | AirTunes | 94.9Bathroom Stereo Off | Computer | AirTunes | 94.9All Rooms Stereo Off | Computer |AirTunes | 94.9All Lights Off | All Lights On Wake Radio: Disable |Enable
Michel Kohanim Posted January 4, 2013 Posted January 4, 2013 Hi bTwix, Unfortunately not. It's going to be pretty difficult to figure out what URLs require authorization and which ones don't. With kind regards, Michel
bTwix Posted January 4, 2013 Author Posted January 4, 2013 How about a global checkbox that allows anonymous access to "/rest/*" and "/user/*"? Thanks for considering it. Phil
Michel Kohanim Posted January 4, 2013 Posted January 4, 2013 Hi Phil, We would certainly consider it. With kind regards, Michel
Michel Kohanim Posted February 15, 2013 Posted February 15, 2013 Hi Phil, Unfortunately we have decided not to implement this feature since it will completely break our security model. This said, we have decided to look further into authentication/authorization. With kind regards, Michel
bTwix Posted June 26, 2013 Author Posted June 26, 2013 Thanks, Michel. For authentication/authorization, an anonymous access feature by resource would be ideal: - /programs - /user/web - /vars - /elk - ... Since we have a secure network, if they have physical access to an Ethernet jack they also have physical access to the light switches, TV remote, etc. I appreciate that not all users may want anonymous access, but it definitely simplifies ease of use and wife approval factor.
Michel Kohanim Posted June 26, 2013 Posted June 26, 2013 Hi bTwix, Thanks so very much for the suggestion and feedback. This has been on our requirement list for a VERY long time. The reason is that every time we try to implement it, we face much deeper security challenges. As far as the wife factor, most http clients support Basic Authentication. Is it difficult to hardcode ISY's userid/password in your client? i.e. I am just delegating the security hole back to your client With kind regards, Michel
arw01 Posted June 26, 2013 Posted June 26, 2013 I have wondered why you could not use certificates on the mobile device and have the ISY check it? Or a SSH type arrangement where you have to specifically allow rsa keys' to have them talk.
Michel Kohanim Posted June 26, 2013 Posted June 26, 2013 Hi Alan, You could do that with PRO series. This said, this will make ISY not accessible to any device that can do https BUT not client authentication. With kind regards, Michel
arw01 Posted June 26, 2013 Posted June 26, 2013 Thanks Michel. Could someone elaborate on how one could tell if your device can support this specifically? E..g. does chrome on android support this vs the device supporting this. I assume mobilinc supports this method.
bTwix Posted June 26, 2013 Author Posted June 26, 2013 Hi bTwix, Thanks so very much for the suggestion and feedback. This has been on our requirement list for a VERY long time. The reason is that every time we try to implement it, we face much deeper security challenges. As far as the wife factor, most http clients support Basic Authentication. Is it difficult to hardcode ISY's userid/password in your client? i.e. I am just delegating the security hole back to your client With kind regards, Michel >> Is it difficult to hardcode ISY's userid/password in your client? No, that's fine. The issue is that I want the ISY web module to *host* the client web page (remote.htm), so if ISY is up I can control the house via remote.htm, even if my home server is offline or gone (future). However since /user/web doesn't support anonymous access, I have to type in the ISY user/pass every time to access remote.htm if hosted with the ISY web module in /user/web. Can you add a checkbox to enable anonymous access to /user/web, so I can host my remote.htm using the ISY web module? I'll hardcode the user/pass in remote.htm for the other REST calls.
Michel Kohanim Posted June 26, 2013 Posted June 26, 2013 Hi btWix, Got it. This is much easier ... thank you. With kind regards, Michel
MWareman Posted June 26, 2013 Posted June 26, 2013 Maybe a per-folder 'Allow Anonymous Access' attribute that can be set - in case we don't want to allow the full /user/web to be accessible? Default it to 'Off' on each folder (so there are no nasty security surprises for anyone). So, for example, I could write log files to /user/web/logs, and authentication would be needed, but an 'index.html' could be served without authentication from /user/web Just my $0.02. I'd make much better use of the user web space on the ISY with this feature.
Michel Kohanim Posted June 27, 2013 Posted June 27, 2013 Hi Michael, This is precisely why every time we try to add anonymous, it immediately becomes a huge requirement to revamp authorization in ISY. Adding a simply boolean at /USER/WEB is easy. Adding a password file for each directory requires investigation of what we ultimately want to do. With kind regards, Michel
bTwix Posted July 2, 2013 Author Posted July 2, 2013 >> Adding a simply boolean at /USER/WEB is easy. Adding a password file for each directory requires investigation of what we ultimately want to do. Agree. I'd prefer to keep it simple to start (vs. getting nothing). Per directory security would be nice to have, but not required for 80% of the value. >> Default it to 'Off' Agree.
MWareman Posted July 2, 2013 Posted July 2, 2013 How about a simple variation on .htaccess..... If there is a .anon file in the directory that the file being requested is in, allow anonymous access. Otherwise, require authentication. It's then up to us to create the .anon file if we choose to allow anonymous to that folder and all files within. Should be easy to implement, and shouldn't break anything (since default would be to require auth). Gives more than 80% I think. And does not need a full revamp. Now, password-less access to the REST interface I agree is a bit more challenging. I would think the ISY could store one or more 'authorization' strings - and if one of the strings is supplied as a REST parameter, authentication is bypassed. Simple enough.. A bit like API tokens are generated and used by NotifyMyAndroid, Prowl and Pushover (all do this exact thing). ISY is easier because its a single user system.
Michel Kohanim Posted July 2, 2013 Posted July 2, 2013 Hi Michael, ISY is not Linux based so whatever we do is going to be from scratch. .password and .anon are basically the same (or reverse of each other) and something we are definitely considering. Again the simplest path forward is to make /USER/WEB directory either protected or not protected. With kind regards, Michel
ticklemeozmo Posted August 13, 2013 Posted August 13, 2013 I like the ".anon" for /USER/WEB/ I like the API KEY for the REST interface (even just one). Especially as I look to integrate with other things. When can we expect at least the .anon portion?
Michel Kohanim Posted August 13, 2013 Posted August 13, 2013 Hi ticklemeozo, Unfortunately we do not plan to provide any unrestricted access to ISY especially given all the reports of security holes/attacks to home automation devices. With kind regards, Michel
ticklemeozmo Posted August 13, 2013 Posted August 13, 2013 An API Key in the URL over SSL is hardly "unrestricted". I'm pretty sure that: //192.168.1.100/rest/nodes/12345/key/772ac1a55fab1122f3b369ee9cd31549/cmd/dof is much more secure than: //admin:admin@192.168.1.100/rest/nodes/12345/cmd/dof My first guess on any basic authentication mechanism is going to be "admin:admin". It's going to take a while before you guess my api key. Even unencrypted, the api key still gives me a fighting chance over basic authentication. With multiple API Keys, I can revoke certain devices. Rather than having to change my password on my other n-1 devices because a password leaked. Respectfully.
Michel Kohanim Posted August 14, 2013 Posted August 14, 2013 Hi ticklemeozmo, You are 100% correct and I am not disputing that API keys are more secure. This said, currently we do not have that framework and it'll require much development and major regression testing. At the moment, we do recommend: a) Changing the certificate Accessing ISY using HTTPS when outside (even inside) c) Change your password With kind regards, Michel
giesen Posted August 14, 2013 Posted August 14, 2013 Michel, While we're discussing authentication, would it be possible to implement HTTP Digest authentication (RFC 2617 - http://tools.ietf.org/html/rfc2617) instead of HTTP Basic Authentication? SSL is just too unacceptably slow (takes about 5-10 seconds to turn off a light switch from eKeypad vs almost instantaneous using plain HTTP) but I'd like to have more protection of my password than plain HTTP Basic Authentication provides (that is, none). Is this a possibility?
Michel Kohanim Posted August 14, 2013 Posted August 14, 2013 Hi giesen, Yes we can but even that requires development. I am concerned that SSL is taking too long. It should NOT if the client (i.e. eKeypad) uses session resume. It should only take 10 second on the initial connection. The rest should be just a little longer than http (still less than a second). With kind regards, Michel
arw01 Posted August 14, 2013 Posted August 14, 2013 I had not come across resume, does that mean the same subscription that was closed, or something else? Where specifically in the rest docs would I find that one?
Recommended Posts