The Vera Community forums have moved!

Advanced => Security => Topic started by: 325xi on August 17, 2009, 11:17:55 pm

Title: Session management & authentication
Post by: 325xi on August 17, 2009, 11:17:55 pm
Vera allows to do a lot of stuff by HTTP GET, such as
http://ipaddress:49451/data_request?id=lu_action&output_format=xml&DeviceNum=6&serviceId=urn:upnp-org:serviceId:SwitchPower1&action=SetTarget&newTargetValue=1

There's no authentication and session management, which means Vera relays on firewall only, which in turn means there's no way I can access it from outside. This limits some interesting options: some 3rd party services could enable to use dial-in voice recognition (dial2do.com for example), and controlling the house using external IVR that does HTTP GET anywhere on specific command.

Would you consider adding authenticated access?

Typical 'easy' scenario could be as following:
- accessing system has to auth via SSL
- on access Vera checks session cookie, and doesn't allow control from outside in not logged in
- session expires in X min if not accessed

In its basic form it's peanuts to implement - what do you think?
Title: Re: Session management & authentication
Post by: LibraSun on August 17, 2009, 11:36:04 pm
I like the authentication options you're proposing, 325xi, and if you don't mind, I'd like to throw in another suggestion, since it follows in principle what you're striving toward...

Let us email Vera through FindVera.com!

Consider these options:

1. Pre-authorize certain email addresses and/or incoming SMS numbers...
2. Set up a basic 'HELP' facility so I could email/text 'Help', and Vera would respond with a list of verbs (TURN ON, SET, etc.), devices (Thermostat, Lock, etc.)... so we can be reminded how to send a well-formed request...
3. And these requests would be sent to, say, 325xi-58334@findvera.com...
4. And relayed directly to Vera, who would/could follow up with confirmation.

This would be a helpful adjunct on occasions when we don't have Web access, but can still send MMS, SMS or (as 325xi pointed out) speech-to-text command requests through an appropriate conduit.

In a perfect scenario, Vera could be made to understand language like, "in 40 minutes" or "tomorrow at 8 am", etc.  All of which could easily find its way into a Luup plug-in, I suppose.

Is this way off base from what you're after?

By the way, as a user of JOTT.COM, I thank you for mentioning Dial2Do.com ... how incredibly useful!
Title: Re: Session management & authentication
Post by: LibraSun on August 18, 2009, 12:44:52 am
By the way, 325xi, I must assume you've already read the
"Accessing Vera remotely through the findvera server" section of:

http://wiki.micasaverde.com/index.php/UI_Notes#The_HTTP_interface

Which discusses the HTTPS > FindVera.com > GET/REST request
method of retrieving data from Vera, securely.  I'm hoping this is at least a step in the direction of your original question.
Title: Re: Session management & authentication
Post by: 325xi on August 18, 2009, 08:33:59 am
I totally forgot about it - thanks for pointing me.
Title: Re: Session management & authentication
Post by: micasaverde on August 19, 2009, 10:11:56 pm
Since FindVera is now free, that's the recommended way of accessing Vera remotely securely.  Of course, you could always forward ports 80 and 49451 from your firewall, but it would be hackable.
Title: Re: Session management & authentication
Post by: 325xi on August 19, 2009, 10:52:01 pm
Of course findvera.com is better option, no doubts about that. My concern though is that user's credentials are part of the command, in plain text. It's going to be too easy to sniff or intercept.

It would be much more secure if you allowed proper session management: special authentication command to open HTTP session; then actual commands would go without explicit authentication, and the session would eventually expire if not accessed - just like any secure service works.
Title: Re: Session management & authentication
Post by: LibraSun on August 19, 2009, 10:58:26 pm
@325xi, are you perhaps suggesting FindVera have "Require HTTPS Connection" as an option, the way GMail currently does?

At least, in this way, security-sensitive users would navigate to FindVera using https://findvera.com, and then do a standard (but secure) username/password login there.

Those who don't fear their un/pw info floating around in cyberspace, for packet sniffers to get a whiff of, could simply leave the option unchecked, and pass that info in the URL as current documentation suggests.

Is this doable?  Does it cover all the security bases?
Title: Re: Session management & authentication
Post by: 325xi on August 19, 2009, 11:11:03 pm
No, this entire subject is not so much about users and UI, but about 3rd party systems interfacing with Vera. Even though it's SSL connection, having credentials as part of base URL doesn't feel right. URL can be viewed, copied, emailed, cached, and otherwise shared in many ways. This is why I strongly suggest to separate authentication and commands.
Title: Re: Session management & authentication
Post by: micasaverde on September 03, 2009, 12:42:52 pm
When you login through findvera or use the mobile phone app through findvera, we do not pass the username and password on the URL--we use session authentication to keep it secure.  So this doesn't effect the findvera site or the mobile phone apps.

The ability to pass the username/password as parameters on the URL was done when Vera first came out to make it really easy for advanced users who wanted their own scripts to do certain things.  For example, you could have an icon on your computer at work that is simply a batch file 'wget https://ra1.findvera.com/user/pass/turn_ac_on_stuff' that you click before leaving work to turn on the air conditioning.

The introduction of the Z-Wave lock has changed things, though.  A competitor has been suggesting to our dealers that Vera's ability to add-on 3rd party controls represents a security risk.  Of course, that's not really fair.  A normal user will just use the services we provide, like findvera and our phone apps, and those are secure, and your credentials are not compromised.  It's really only very advanced, highly technical geeks who will be doing things like passing usernames/passwords through control URL's in scripts running on remote computers, and thus introducing the vulnerabilities.  The types of users who would do this are well aware of the security implicatations, of, say, storing their username/password in a batch file at work.

So, we're trying to find the right balance.  On the one hand, we could force all remote access from 3rd party apps and scripts to go through the same login/authentication like we do for findvera and mobile apps.  That way we wouldn't allow any access that wasn't secure.  But, the flip side is that Vera does a lot of stuff that doesn't involve secure door locks and we don't to 'punish' a user who knows what he's doing, doesn't even have a door lock, and simply wants an easy way to turn on his a/c remotely without logging in to findvera.

We have the same issue with access on the local network within the home.  Other products, like the Schlage LiNK, don't allow local network access.  It enforces security, but also means you can't use your system without their service, and makes tasks like infrared control of tv's impossible--imagine the lag time if when you hit 'volume up' on your iPhone remote the request has to get encrypted, sent to a remote secure server over the internet, then re-encrypted, sent back to the home-owner's bridge, which then sends the i/r code to the TV.  It would be so slow it would be totally unusable.  So, our solution was to leave local network access on, but have a big bold warning next to any door lock devices letting the user know that if he compromises his home network, such as installing an wi-fi access point without security, he'll introduce a security vulnerability that could allow a hacker to gain access to the locks.

Specifically regarding passing the username and password on the URL, we discussed maybe disabling that ability, but still allowing them to be passed in as form submit variables.  It would make it harder to write remote scripts, but at least the scripts would be more secure.

Title: Re: Session management & authentication
Post by: LibraSun on September 03, 2009, 01:04:33 pm
To continue with this thinking, MCV, you could also hard-wire a "Make a Shortcut" function into Vera which:

(a) Prompts the user for his credentials (or grabs them internally in Vera)
(b) Allows the user to pick-and-choose what Commands (or Scenes) the shortcut should run
(c) Creates and encrypts the necessary URL
(d) Uploads the shortcut's "key" to the user's FindVera account
(e) Offers a "Save Shortcut" button that lets the user save the shortcut to his hard drive or Desktop

A sample output might look like:
     http://ra1.findvera.com/shortcut?key=5bG7WfZ12C&name='Coming_Home'

...where the last parameter is simply a 'comment' for the user's convenience in recalling what shortcut '5bG7WfZ12C' is supposed to do.

I know I've requested this "Feature" elsewhere in the Forum, but now see it more as a security issue than a matter of convenience, and the "Make a Shortcut" function I'm proposing would provide both, plus spare users from having to compose their own 'port_49451'-style URLs (which are ugly and cumbersome).

Thoughts?
Title: Re: Session management & authentication
Post by: 325xi on September 03, 2009, 11:44:19 pm
What you described is somewhat similar to session authentication, just if session never expired. But one of the reasons to expire session on timeout is to prevent bad guys to reuse authenticated session (URL in your case).
And this static thing can easily copied and reused by anybody.
Title: Re: Session management & authentication
Post by: LibraSun on September 04, 2009, 12:00:17 am
Valid point, 325xi, but of course the entire point of allowing ANY shortcuts or URL access to Vera is repeatability and a de facto API to her functionality.

The system I described would at least allows such things as (1) enumerating how many times a link/shortcut was used, (2) recording the IP address of where the shortcut originated, (3) user's ability to retire (inactivate) the shortcut, and (4) allow the shortcut to remain editable throughout its life.
Title: Re: Session management & authentication
Post by: micasaverde on September 08, 2009, 10:59:56 pm
BTW, just to be sure we're on the same page, the username/password that are passed on the URL like we do are still encrypted.  As I re-read an earlier post it makes sound like the authentication is passed around on the internet in clear text.  But that's not true, a URL on https is encrypted.  So the authentication is still secure.  The vulnerability is that if the user puts a batch file, for example, on his computer at the office, which contains the username and password, then if somebody gets into his office computer, the intruder can find the batch file and read the username/password from it.  This same vulnerability exists even with online banking and other secure sites because a lot of users choose the browser option to 'store the password', which, again, means if an intruder has access to the person's computer, they can login to his online banking, etc.  So is having the username/password stored in a batch file or a shortcut on the desktop more of a vulnerability than using the web browser's "store my password"?  The truth is if a user (a) had a script which did some automated thing using the username/password on the URL, and (b) used the browser's "store my password" feature to save his findvera password, and then an intruder got to his computer, which would be the greater vulnerability?  My guess is the stored password because the intruder would bring up the browser, see the history, click findvera (and his online banking, etc.) and gain access.  An intruder probably wouldn't even notice the batch file he uses to automate some task. 

http://mattfleming.com/node/289
http://blog.httpwatch.com/2009/02/20/how-secure-are-query-strings-over-https/
http://stackoverflow.com/questions/323200/is-a-https-query-string-secure
http://answers.google.com/answers/threadview/id/758002.html
Title: Re: Session management & authentication
Post by: atlantis94fr on October 05, 2010, 05:31:30 pm
Hello

Reading this topic, I don't understand why you, MiCasaverde, are locked on the server level managed accounts and authentication principle.

The vera is a private device used in a private environment. The security bubble that covers such a private environment in my opinion must manage it's own accounts and passwords.

I Agree a SLL/HTTP  is secure concerning data flow protection but such a mechanism might be available directly from vera Web server.

Regards
Title: Re: Session management & authentication
Post by: umtauscher on October 08, 2010, 06:26:31 am
Just to add my 2 Cts again:
For the record:

Vera doesn't work properly without an internet connection. It constantly "phones home" and many functions simply don't work without MCV servers.

If you are able to telnet into the box, you may be able to circumvent some of the problems.
Anyway the whole plugin management doesn't work without internet.
This means, when MCV goes out of business, you can throw you Vera into the bin.

I firewalled my Vera as good as I could from the internet so I have at least control about the time it is able to contact the MVC server(s).

Anyway this is really unacceptable to me and this is the major concern why I:
1. Will not upgrade my vera1 to vera2
2. I am searching for an alternative.

Cheers
Umtauscher
Title: Re: Session management & authentication
Post by: atlantis94fr on October 08, 2010, 06:41:38 am
Hi umtauscher     


Happy to see that I am not the only guy to feel that there is a very big problem in the vera security principles concerning accounts/rights managment  and links with MVC servers.

In am affraied we can easily imagine a backdoor usage for the vera on our networks. !!!

This is unacceptable...

regards
Title: Re: Session management & authentication
Post by: umtauscher on October 08, 2010, 06:54:41 am
Hi atlantis94fr,

I understand what you mean but what I am really NOT happy about, is how unprofessionally MCV works. The concept went from open and friendly to closed and suspicious.

At the moment I really doubt, that  MCV are really that naive about our concerns. I rather tend to the conclusion, that their real intent is to have backdoors into as many homes as they can get.

Cheers
Umtauscher
Title: Re: Session management & authentication
Post by: atlantis94fr on October 08, 2010, 07:06:11 am
Hello,

I agree with you , I'll lock outgoing flows to internet in my Firewall vera dedicated DMZ as soon as I go back home tonight ...

Better to avoid any alien access to home security devices...

It will be my choice too, waiting for answers and/or security process managment modification/improvment from MCV...

Regards
Title: Re: Session management & authentication
Post by: JOD on October 08, 2010, 09:52:07 am
atlantis94fr, umtauscher,

Are you thinking some sort of conspiracy?

JOD.
Title: Re: Session management & authentication
Post by: atlantis94fr on October 08, 2010, 10:53:09 am

Cannot say anything about it. but such a risk exists.

While I write my vera is perhaps (depending of what has been coded in it, indeed, but we don't know and this a part of the problem) full opened for the MCS people eyes....

The only way to secure it today is to cut the link with Internet.

However, the security options for vera/MCS servers seems not "state of the art" regarding security mecanism requested for professional IT systems.

Usage of such a device would be refused by IT security staff in any company which is concerned by those topics... Very often a solution is refused or seriously discussed by one of my customer because of unsecured solution concerning data flows managment.

My opinion is that from the point of view of Home automation Vera addresses very well the subject but not today  from a security point of vue...

That's all !!!
Title: Re: Session management & authentication
Post by: JOD on October 08, 2010, 11:21:15 am
Interesting and I totally agree.

The thought of superfluous code being in the FW that would allow back door access has crossed my mind in the past, and the fact MCV has the serial number / MAC address of every Vera sold.

JOD.
Title: Re: Session management & authentication
Post by: atlantis94fr on November 04, 2010, 04:51:43 pm
However very curious MCV does not even try to comment about suppositions concerning vera usage as a backdoor...
Title: Re: Session management & authentication
Post by: Dano87 on January 09, 2011, 10:55:35 am
Earlier in this post, umtauscher say he was searching for an alternative to vera due to these concerns.  Any luck? 

I really don't understand MCV logic on this change.  They are now taking a larger liability risk by requiring all users to use their MOIS server security method vs. letting the user have a choice.  As someone said, the only 100% secure environment is to disconnect the internet connection and operate on a private LAN.  Vera2 (UI4) doesn not allow this.......it just doesn't make sense.......unless MCV's business plan is to take control of their install-base (like the others - Xanboo, Homesecure, etc.)....say it's not true.

This product has so much potential with an open architecture and community formn that has been developed.  Hopefully, MCV will put the decision back in the hands of the users where it belongs.  This will only make their product a bigger player in the marketplace.