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.
