There are two issues that I feel are security liabilities that I hope ADC and Qolsys will prioritize and address.
The first is that the ADC app does not require entry of a user code to disarm; there should at least be an option to require code entry. This is dangerous, in my opinion, because a would-be attacker familiar with Alarm.com could force someone to disarm the system via the app, thereby circumventing the threat of a duress code being entered. Sure, your phone might be locked, and you might even have to log in to the app (though most users likely remain logged in for efficiency and usability), but what are you going to do if someone has a gun to your head? This is a serious oversight that could potentially rob someone of the opportunity to enter a duress code during a dangerous situation; it diminishes the value of a duress code and could get someone killed. This is why I don’t want a keyfob remote, because someone could use it to easily disarm my alarm absent any authentication.
The second, specific to the Qolsys IQ2, is the Bluetooth disarming feature, for much the same reason as above. While not terribly common, it’s not unheard of for an attacker to wait outside a home and sneak up on a resident who is attempting to enter, then force the individual inside. In this scenario, with Bluetooth disarming active, the phone would automatically disarm the security system upon entry; as above, there would be no opportunity presented for the resident to enter a duress code. The problem is that the Bluetooth disarming feature does not require any secondary authentication. It should. There should be a user-definable delay following Bluetooth disarm, after which a user code must be entered to prevent an alarm. This would allow users to continue leveraging the convenience of the Bluetooth disarm feature (if, for example, one is carrying groceries into the home) while mitigating the risk. Other potential issues with Bluetooth disarming aside, I would not be comfortable using the feature until this problem is addressed.
The second, specific to the Qolsys IQ2, is the Bluetooth disarming feature, for much the same reason as above. While not terribly common, it’s not unheard of for an attacker to wait outside a home and sneak up on a resident who is attempting to enter, then force the individual inside. In this scenario, with Bluetooth disarming active, the phone would automatically disarm the security system upon entry; as above, there would be no opportunity presented for the resident to enter a duress code. The problem is that the Bluetooth disarming feature does not require any secondary authentication. It should. There should be a user-definable delay following Bluetooth disarm, after which a user code must be entered to prevent an alarm. This would allow users to continue leveraging the convenience of the Bluetooth disarm feature (if, for example, one is carrying groceries into the home) while mitigating the risk. Other potential issues with Bluetooth disarming aside, I would not be comfortable using the feature until this problem is addressed.
I do not personally recommend using Bluetooth disarming in its current state as it is easily the least secure feature on the panel. The point of Bluetooth disarming is to remove the need for manual authentication of any kind. The sales pitch is that you’re racing in the house with a bag of groceries and entering a code is an unacceptable hassle. What is this, the middle ages?
It is a solution to a problem which is caused by the way the system is used, the need for which may be questionable.
There is no question that it is convenient, and there is a cool factor that can’t be beat, but there are real costs for the convenience.
It is especially problematic if you Arm Away at night to use motion detectors. Consider a phone that restarts at night, reconnecting Bluetooth at 3AM and disarming the system. We’ve had users report this type of behavior, which is easy to anticipate.
The first is that the ADC app does not require entry of a user code to disarm; there should at least be an option to require code entry. This is dangerous, in my opinion, because a would-be attacker familiar with Alarm.com could force someone to disarm the system via the app, thereby circumventing the threat of a duress code being entered. Sure, your phone might be locked, and you might even have to log in to the app (though most users likely remain logged in for efficiency and usability), but what are you going to do if someone has a gun to your head? This is a serious oversight that could potentially rob someone of the opportunity to enter a duress code during a dangerous situation; it diminishes the value of a duress code and could get someone killed. This is why I don’t want a keyfob remote, because someone could use it to easily disarm my alarm absent any authentication.
I think that asking all millions of ADC app users to further authenticate on top of the existing process may be a tough sell in terms of the natural disarm process in the app.
Any change with this regard would likely need to be opt-in. One thing that is probably do-able, and I’m going to suggest it to ADC, is to make use of the device PIN access code as well as the in-app panel panic, and be able to set up a duress code of sorts in addition to the access pin.
What I am referring to is found under App Settings in the menu. You can set a 4 digit pin code to be required for use of the app each time, so you can stay logged in but still require authentication to access app features. This is an opt-in feature. It may be possible to tie in the in-app panel panic and then set an additional code to be used as a virtual duress which would surreptitiously activate the in-app panel panic. I can’t say for certain whether that would be implemented, (though it may already be in the works) but I do think it is a good idea and we’re happy to push it on ADC.
The sales pitch is that you’re racing in the house with a bag of groceries and entering a code is an unacceptable hassle.
I currently have Bluetooth disabled, and it will remain so unless Qolsys adds an option to require secondary authentication of disarm commands following a user-definable delay. If I could set a delay of two or three minutes following Bluetooth disarm, after which the alarm will activate if my code hasn’t been entered, that would permit me convenient entry while my hands are full while mitigating the risk described above. What I’m proposing is relatively similar in concept to crash and smash protection, whereby a signal is communicated to the monitoring station and the panel is presumed to have been destroyed if a disarm command is not received or the panel subsequently goes offline. In this case, the panel would be programmed to initiate an alarm if a disarm or duress code isn’t entered within a specified time following a Bluetooth disarm event; so, in a sense, the Bluetooth disarm feature would function more as a convenience grace period rather than a true disarm.
It is especially problematic if you Arm Away at night to use motion detectors.
That’s also concerning. Although, I would question why those motion detectors aren’t configured for stay arming, rather than arming in away mode as a workaround? I guess some systems or motion sensors don’t provide that option? I know it can be done with the IQ2 Plus and PowerG sensors.
Regarding ADC app:
I think that asking all millions of ADC app users to further authenticate on top of the existing process may be a tough sell in terms of the natural disarm process in the app.
I agree that a lot of users might object due to inconvenience, though many people probably haven’t considered this potential liability either. I’m fine with it being a user-selectable option, but the option should exist.
Any change with this regard would likely need to be opt-in. One thing that is probably do-able, and I’m going to suggest it to ADC, is to make use of the device PIN access code as well as the in-app panel panic, and be able to set up a duress code of sorts in addition to the access pin.
What I am referring to is found under App Settings in the menu. You can set a 4 digit pin code to be required for use of the app each time, so you can stay logged in but still require authentication to access app features. This is an opt-in feature. It may be possible to tie in the in-app panel panic and then set an additional code to be used as a virtual duress which would surreptitiously activate the in-app panel panic.
This would be fine, too, as it would essentially achieve the same goal if a secondary duress pin could be entered. I don’t use the pin as it’s currently implemented, because my phone remains locked whenever set down, and in the scenario I’ve described an attacker would simply force you to unlock it.
That’s also concerning. Although, I would question why those motion detectors aren’t configured for stay arming, rather than arming in away mode as a workaround? I guess some systems or motion sensors don’t provide that option? I know it can be done with the IQ2 Plus and PowerG sensors.
Because those motion detectors may not always need to be armed in Stay mode, in fact very commonly they are not.
The only real functional difference between arming away and stay is interior followers. It is very common to have reason to arm the system with people at home and not arm the motion detectors, and at night arm the system including the motion detectors.