Presumably not from a security point of view?

 

From a design pov it does make sense, providing the need for absolutely zero

additional training or familiarity should someone used to using the hardware

decide to use the app long after the installer has explained the system...

 

The obvious limitation I see on phones, not specifically alarm software, is the limitation to 4-6 digit numeric pins, when  you have a full QWERTY keyboard available to you. 

 

From a design point of view, it can make sense, but often doesn't. I've got oscilloscope software that requires precise circular rotation to make the dials work and the toggle switches just look depressed using a little shadow when they are in. It's awful. 

Yeah something like a scope there is no excuse for, analogue dials just don't work full stop.

 

4/6 digit pins thats very true, I have hounded Cooper (iOn) to copy Siemens (SPC) and have a separate A/N p/w

for the www browser login, not bloody 1234 or whatever!

 

However, don't forget any attempt to number gen on an emulated keypad will simply result in the alarm sounding

for keppad tamper same as if you were in the property - have checked this with the iOn.

The obvious limitation I see on phones, not specifically alarm software, is the limitation to 4-6 digit numeric pins, when  you have a full QWERTY keyboard available to you. 

 

 

Most of alarm software like this I have seen has Username, Password and then Panel code to login.

Should we be worried about a MITM attack and people discovering alarm codes?

Not hard to use keyloggers and find a persons address?

No harder than stealing keys + fob!

 

However, don't forget any attempt to number gen on an emulated keypad will simply result in the alarm sounding

for keppad tamper same as if you were in the property - have checked this with the iOn.

 

Yep, and that alone could render the system useless.  Ie. Anyone who gains a connection can cause havoc.  My advice is always to use a decent router and connect via VPN tunnel to any embedded devices on internal networks. Don't just port forward to devices that may have firmware vulnerabilities.

I wouldn't use PF at all, IMO for simplicity and security Webway is the way forward as regards subsiduary webserver / mobile app connections to panels.

 

The average domestic customer wants these features today and isn't going to be told they need to buy/configure a new router.

With almost 2k installs of my Galaxy based VirtualKeypad app, it's clear that  it's something that people are interested in.

 

I thought that webway requires the user to wait on the next poll for the embedded device to open a reverse tunnel to the panel (someone please correct me here as I don't have direct experience of this).  Anything over a few seconds to connect is going to be too much.

Not anymore that was the case a while ago though

With almost 2k installs of my Galaxy based VirtualKeypad app, it's clear that it's something that people are interested in.

I thought that webway requires the user to wait on the next poll for the embedded device to open a reverse tunnel to the panel (someone please correct me here as I don't have direct experience of this). Anything over a few seconds to connect is going to be too much.

That depends. For direct hosted architecture if you didn't have (a very expensive) modem on the back of the MCTs you had to wait for the poll. If you have the modem it sends a text to the SPT to tell it you want to have a conversation with it. Works very well for g2 GPRS only sites. Hosted platform isn't an issue.

That's not the case anymore matt that's the old way