We have moved at community.getvera.com

Author Topic: Session management & authentication  (Read 16190 times)

Offline 325xi

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 1101
  • Karma: +0/-0
  • V1, V2, still V2...
Session management & authentication
« 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?

Offline LibraSun

  • Hero Member
  • *****
  • Posts: 574
  • Karma: +2/-0
Re: Session management & authentication
« Reply #1 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!
« Last Edit: August 17, 2009, 11:41:51 pm by LibraSun »
Vera Model I running UI4 (Firmware 1.1.1338), died in 2015
Vera Plus running UI7 (Firmware 1.7.2935)

Offline LibraSun

  • Hero Member
  • *****
  • Posts: 574
  • Karma: +2/-0
Re: Session management & authentication
« Reply #2 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.
Vera Model I running UI4 (Firmware 1.1.1338), died in 2015
Vera Plus running UI7 (Firmware 1.7.2935)

Offline 325xi

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 1101
  • Karma: +0/-0
  • V1, V2, still V2...
Re: Session management & authentication
« Reply #3 on: August 18, 2009, 08:33:59 am »
I totally forgot about it - thanks for pointing me.

Offline micasaverde

  • Hero Member
  • *****
  • Posts: 1666
  • Karma: +15/-1
Re: Session management & authentication
« Reply #4 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.

Offline 325xi

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 1101
  • Karma: +0/-0
  • V1, V2, still V2...
Re: Session management & authentication
« Reply #5 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.

Offline LibraSun

  • Hero Member
  • *****
  • Posts: 574
  • Karma: +2/-0
Re: Session management & authentication
« Reply #6 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?
Vera Model I running UI4 (Firmware 1.1.1338), died in 2015
Vera Plus running UI7 (Firmware 1.7.2935)

Offline 325xi

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 1101
  • Karma: +0/-0
  • V1, V2, still V2...
Re: Session management & authentication
« Reply #7 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.

Offline micasaverde

  • Hero Member
  • *****
  • Posts: 1666
  • Karma: +15/-1
Re: Session management & authentication
« Reply #8 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.


Offline LibraSun

  • Hero Member
  • *****
  • Posts: 574
  • Karma: +2/-0
Re: Session management & authentication
« Reply #9 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?
Vera Model I running UI4 (Firmware 1.1.1338), died in 2015
Vera Plus running UI7 (Firmware 1.7.2935)

Offline 325xi

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 1101
  • Karma: +0/-0
  • V1, V2, still V2...
Re: Session management & authentication
« Reply #10 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.

Offline LibraSun

  • Hero Member
  • *****
  • Posts: 574
  • Karma: +2/-0
Re: Session management & authentication
« Reply #11 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.
Vera Model I running UI4 (Firmware 1.1.1338), died in 2015
Vera Plus running UI7 (Firmware 1.7.2935)

Offline micasaverde

  • Hero Member
  • *****
  • Posts: 1666
  • Karma: +15/-1
Re: Session management & authentication
« Reply #12 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

Offline atlantis94fr

  • Sr. Newbie
  • *
  • Posts: 23
  • Karma: +0/-0
Re: Session management & authentication
« Reply #13 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

Offline umtauscher

  • Full Member
  • ***
  • Posts: 223
  • Karma: +0/-0
Re: Session management & authentication
« Reply #14 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