schwark / smartthings-alarmcom

SmartThings Integration with alarm.com
MIT License
61 stars 131 forks source link

Alarm.com started using two-factor Authentication - Stopped it working from Smarththings #39

Closed vhanna70 closed 2 years ago

vhanna70 commented 3 years ago

My Alarm.com Smartthings plugin stopped working a couple of days ago. Around the same time that I noticed Alarm.com is asking me to set up 2 factor authentication. I am assuming the code will not be able to access what it needs to until you can get the login to go past the request to set-up or sklp the two-factor authorization page.

From playing in Home Assistant i noticed that their code was able to login into Alarm.com because it was using Cookie Token that I had to get from my Alarm.com web page once logged in. two_factor_cookie: '0B663777777710A42FCFFB2755555EA6C017EA171974A5F69C47BD7BCF2EBE53' Not that this working completely in Home Assistant - URL - Post Login page in their code is not accessable to me. I have a different landing page.

You may need to look at some how by passing the two-factor authorization to get this working again.

crizo23 commented 3 years ago

Lots of similar reports in the past week. I don't think it's specifically a 2 factor thing, possibly more of an overall authentication flow change. I watched the SmartThings IDE live logging and see a similar "two factor" cookie (?) being passed around in a "debug navigation" log entry. The property name is twoFactorAuthenticationId

schwark commented 3 years ago

So I have looked into this. It is in fact the two-factor signup popup that shows up.. For this reason, it works intermittently for me. I have not found a way to reliably click around the two-factor signup flow. Still looking into it..

crizo23 commented 3 years ago

It is in fact the two-factor signup popup that shows up..

OH sure it's the initial 2FA popup on the site, good call. And like you said, even the pop-up on alarm.com is intermittent, which makes sense whey the smartapp success is intermittent. Shame on alarm.com for having such a poor site design choice: if I chose "no" to 2FA, that should stick and I not be asked again.

🥂 cheers to @schwark for all the work on this.

ryangottlieb commented 3 years ago

FYI having the same issue. I wrote them about the 2FA not remembering I hit skip. They pretty much said deal with it.

crizo23 commented 3 years ago

I'll bug them too. But yeah in the past they haven't been receptive to feedback. They even blocked me on twitter for asking questions. Alarm.com is such a weird, siloed system.

Also, @schwark I updated my app after the recent commits above. I still see error something went wrong: groovyx.net.http.HttpResponseException: Forbidden - I'm sue you're aware. Thanks!

schwark commented 3 years ago

@crizo23 interesting that it is not helping for you. It seems to have worked 50% more times for me since my commit - which is I think all but one so far since the commit. I may have just gotten lucky so far. That forbidden means that it ran into that two factor thing. I am thinking about an auto-retry, x times if it runs into that, to possibly increase success rate. will look into that next.

crizo23 commented 3 years ago

@schwark It's interesting, my disarm switch works every time. Arm-stay/Arm-away are not working. I double checked that my smartapp and device handler code is current.

FYI..I'm testing by toggling the virtual switches in SmartThings.

Once in a while I'm not even getting the Forbidden error. When this happens, the logs look ok, but still my alarm.com system did not arm. Here's the log:

debug sending event off to ARMAWAY
debug sending event on to ARMSTAY
trace response status is 302 for login and uri:https://www.alarm.com/web/Default.aspx
debug getRecipe got command: silent is true and nodelay is false and bypass is false and command is ARMSTAY and COMMAND is [params:[command:/armStay, silent:true, nodelay:false], name:Arm Stay, button:true] and panelid is 94046151-127
debug getCommand got command ARMSTAY with silent true and nodelay of false
debug trying to update status of child device DISARM
debug getCommand got command null with silent true and nodelay of false
debug navigation::post https://www.alarm.com/web/api/devices/partitions/94046151-127/armStay
debug navigation:[name:ARMSTAY, method:post, requestContentType:application/json; charset=UTF-8, <redacted stuff>
debug navigation:[name:login, uri:https://www.alarm.com/web/Default.aspx, method:post, <redacted stuff>
debug state variable afg set to from cookie
debug navigation::get https://www.alarm.com/login.aspx
debug navigation:[name:initlogin, uri:https://www.alarm.com/login.aspx, headers:[Host:www.alarm.com, User-Agent:Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_4) <redacted stuff>
debug switch got command ARMSTAY with silent true and nodelay of false and bypass of false
debug runCommand got command ARMSTAY with silent true and nodelay of false and bypass of false
crizo23 commented 3 years ago

@schwark not sure if you're looking for feedback, but I have the same issue after your last commit. Also, not sure if you my comment above, but Disarm works every time using the disarm trigger works every time. I thought this was interesting considering authentication must be the same with arm and disarm

schwark commented 3 years ago

Yeah the retry does not seem to be helping - I may need to reset entire state before retries. Will try to do that when I get some time. As for the disarm working vs arm, that may have to do with time of day as I also notice that at certain times of day like in the morning it works much more reliably than at night - meaning the two factor prompts don't show up as much during the early AM as they do PM.

crizo23 commented 3 years ago

@schwark

I may have found something. I see different request headers for the /disarm and /armStay calls, specifically the afg cookie.

For disarm, I see state variable afg set to xxxxxxx from cookie (I removed the actual string) and in the /disarm POST call I see: ajaxrequestuniquekey:xxxxxxx

However, for armStay, I don't think a cookie is being set: state variable afg set to from cookie (note the empty string) and the header in the call to /armStay is: ajaxrequestuniquekey:${afg}

I know Javascript, and slowing learning Groovy, so I could be wrong here. Could the afg cookie be the issue?

lastly, I see success responses for both auth related calls, so it might not be a login/two-factor thing.

response status is 302 for login and uri:https://www.alarm.com/web/Default.aspx
response status is 200 for initlogin and uri:https://www.alarm.com/login.aspx
crizo23 commented 3 years ago

@schwark UPDATE! I bugged alarm.com about the annoying two-factor messaging every time I logged on. They responded, telling me I could contact my security provider (who you signed up with) and they can disable the prompt. After my provider disabled it, the smart app virtual device controls to arm work!

schwark commented 3 years ago

@schwark

I may have found something. I see different request headers for the /disarm and /armStay calls, specifically the afg cookie.

For disarm, I see state variable afg set to xxxxxxx from cookie (I removed the actual string) and in the /disarm POST call I see: ajaxrequestuniquekey:xxxxxxx

However, for armStay, I don't think a cookie is being set: state variable afg set to from cookie (note the empty string) and the header in the call to /armStay is: ajaxrequestuniquekey:${afg}

I know Javascript, and slowing learning Groovy, so I could be wrong here. Could the afg cookie be the issue?

lastly, I see success responses for both auth related calls, so it might not be a login/two-factor thing.

response status is 302 for login and uri:https://www.alarm.com/web/Default.aspx
response status is 200 for initlogin and uri:https://www.alarm.com/login.aspx

yeah, that ${afg} means the login never completed - that usually happens when the two-factor shows up. So that is still two-factor showing up.

schwark commented 3 years ago

@schwark UPDATE! I bugged alarm.com about the annoying two-factor messaging every time I logged on. They responded, telling me I could contact my security provider (who you signed up with) and they can disable the prompt. After my provider disabled it, the smart app virtual device controls to arm work!

Great to hear - I called my provider and asked about this as well, and they said they don't know how to do this, but that they will call Alarm.com and see what needs to be done. hopefully they don't get told it cannot be done.

ryangottlieb commented 3 years ago

GeoArm had no idea when I called them.

I’m finding out something else is weird. At work I get no 2FA questions. At home on wifi I do. On cellular, I don’t.

My home internet all runs through a vpn due to type of internet provider (rural area via cell)

schwark commented 3 years ago

if you are getting 2FA questions, that probably means you activated the 2FA on the account - then it is really hard to get around. Those questions only show up on unauthenticated IPs - meaning if you answer them once from a given IP, you typically will not be prompted again from that IP - that may be what is going on with your account. Work IP and cellular IP are authenticated at some point in the past, and maybe home was not? just hypothesizing.

If you disable 2FA, it occasionally prompts you to activate it. That is what is potentially possible to work around. This is one the provider may be able to disable the nags for.

ryangottlieb commented 3 years ago

Sorry I should of clarified. It’s just the alerts to activate it. I never did activate it.

crizo23 commented 3 years ago

keep pushing to have your provider disable it, my guy was able to do it easily.

crechtoris82 commented 3 years ago

Here was the response from my provider:

Comments: Happy to assist. Two-Factor Authentication pop ups through Alarm.com can only be disabled by enabling Two-Factor authentication, they will otherwise return. Two-Factor Authentication is supposed to be made mandatory by Alarm.com at some point in the near future.

crizo23 commented 3 years ago

Here was the response from my provider:

Comments: Happy to assist. Two-Factor Authentication pop ups through Alarm.com can only be disabled by enabling Two-Factor authentication, they will otherwise return. Two-Factor Authentication is supposed to be made mandatory by Alarm.com at some point in the near future.

Very interesting to see how some providers know how to do this, others don't. It's a new feature for the dealers, so I'm sure they're just not yet educated on it.

One of the downsides of alarm.com..no many layers. Also, don't like seeing the "mandatory" statement. This would be very strange, two-factor isn't even enforced by banking systems. Of course, this wouldn't be unlike alarm.com - they're in there own strange walled ecosystem.

ryangottlieb commented 3 years ago

Ive tried 3 times with my dealer. No luck yet.

I used this for automatic scheduling of turning on the alarm ( as well as yelling it at Google). While this is figured out, I found on iOS you can use shortcuts / automation built into iOS can do this for me. I made a shortcut named Arm Stay for example, and just have the automation run the shortcut. In the shortcut if you turn off "Show when run" it wont require your phone to be unlocked.

I know thats just a temp fix for now, hopefully we can figure out the right wording for dealers to know where to find this setting.

schwark commented 3 years ago

keep pushing to have your provider disable it, my guy was able to do it easily.

@crizo23 Can you ask your dealer how they did it so we can all tell our dealers how to do it as well?

crizo23 commented 3 years ago

I kind of did, he just said:

I believe all dealers have this ability but it was only recently that Alarm.com started to heavily push it and turned the notices on for all dealers automatically. If others are as busy as we are, I'm sure they're not as familiar with the process of disabling it yet just as I wasn't until you asked

kpdillon commented 3 years ago

I was able to get my provider to set my alarm.com as exempt. They had to research it a little but they were willing especially after I linked them to this thread. Will the newest code here still work or do I need to rollback to previous version?

schwark commented 3 years ago

Latest version should work.

kpdillon commented 3 years ago

ok, thanks for confirming that. Even though they exempted my account, it is not working with this code anymore and I followed the procedures for removing and re-adding by deleting everything. Even the logs show the commands seem to be successfully sent. On top of that my homekit integration with alarm.com is now working again but this isn't for some reason.

9137a08e-6eca-4a9d-a37b-8143ea43a0ad 5:10:38 PM: debug getChildDevices(false), children=3 9137a08e-6eca-4a9d-a37b-8143ea43a0ad 5:10:38 PM: debug processing switch STATUS with name Status 9137a08e-6eca-4a9d-a37b-8143ea43a0ad 5:10:38 PM: debug processing switch DISARM with name Disarm 9137a08e-6eca-4a9d-a37b-8143ea43a0ad 5:10:38 PM: debug processing switch ARMAWAY with name Arm Away 9137a08e-6eca-4a9d-a37b-8143ea43a0ad 5:10:38 PM: debug processing switch ARMSTAY with name Arm Stay 9137a08e-6eca-4a9d-a37b-8143ea43a0ad 5:10:38 PM: debug getCommand got command null with silent true and nodelay of false 9137a08e-6eca-4a9d-a37b-8143ea43a0ad 5:10:38 PM: debug Creating Alarm.com Switches... 9137a08e-6eca-4a9d-a37b-8143ea43a0ad 5:10:38 PM: debug Doing Alarm.com Device Sync! 9137a08e-6eca-4a9d-a37b-8143ea43a0ad 5:06:17 PM: debug updating status to ARMAWAY on command ARMAWAY 9137a08e-6eca-4a9d-a37b-8143ea43a0ad 5:06:07 PM: debug getCommand got command ARMAWAY with silent null and nodelay of null 9137a08e-6eca-4a9d-a37b-8143ea43a0ad 5:06:07 PM: debug navigation::post https://www.alarm.com/web/Default.aspx 9137a08e-6eca-4a9d-a37b-8143ea43a0ad 5:06:07 PM: debug runCommand got command ARMAWAY with silent null and nodelay of null and bypass of null 9137a08e-6eca-4a9d-a37b-8143ea43a0ad 5:06:07 PM: debug processing recipe login 9137a08e-6eca-4a9d-a37b-8143ea43a0ad 5:06:07 PM: debug navigation::get https://www.alarm.com/login.aspx 9137a08e-6eca-4a9d-a37b-8143ea43a0ad 5:06:07 PM: trace response status is 200 for initlogin and uri:https://www.alarm.com/login.aspx 9137a08e-6eca-4a9d-a37b-8143ea43a0ad 5:06:07 PM: debug navigation:[name:initlogin, uri:https://www.alarm.com/login.aspx, headers:[Host:www.alarm.com, User-Agent:Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/49.0.2623.110 Safari/537.36, Accept:text/html,application/xhtml+xml,application/xml;q=0.9,/;q=0.8, Accept-Language:en-US,en;q=0.5], variables:[:]]

leftride commented 3 years ago

I've hit a brick wall with Brinks Home (my monitoring company). Had a tech from their side and alarm.com on the phone together and Brinks is saying they don't have the ability in their Technical Support group (up through the supervisor level) to exclude my from receiving the 2FA prompt.

freacstomp commented 3 years ago

I completed deleted the Alarm.com app from the Smartthings App as well as from the web portal. I then added them both per the instructions from Schwark. It is not working for me either. I can provide logs if necessary but they seem to be different each time I try to use one of the Arm/Disarm buttons.

digitalrealism commented 3 years ago

So I gave it a shot...I have LiveWatch/Brinks. They didn't know what to do so they conferenced in an alarm.com rep. He said that only the provider can potentially disable the 2FA requirement altogether. My provider is unaware of how to do this. Additionally, the alarm.com rep said that this would be a temporary fix and eventually 2FA will be a requirement for all logins. The guidance for a long-term solution was to enable 2FA and modify the application to support the 2FA process. Not sure what's involved in that or if its even possible. I also asked for some API reference documentation but they claim not to support API access. I wish I had better news but wanted to share the information.

kingd10 commented 3 years ago

Cross posted in smartthing community https://community.smartthings.com/t/alarm-com-and-smart-things/61687/330

I too have noticed my alarm.com/smartthings integration stop working right around when the 2FA pop up started. I first started by uninstalling and reinstalling the device handler and smart app per the instructions. Once that did not resolve the issue I contacted my security service provide, and they were initially not able to disable the 2FA prompts. After some persistent conversation with the rep, he contacted Alarm.com and was able to figure out how to disable it for me. Again after uninstalling and reinstalling everything I am still unsuccessful at arming or disarming my panel.

In the Alarm.com app I can see successful login’s when I push the smartthings buttons. In the Smartthings Log the only error I see if the following: smartthings_alarm

Any help resolving this issue is greatly appreciated!

adrian97c commented 3 years ago

As of 4/26/21 - stopped working. No 2FA prompts.... alarm.cm app doesn’t even show the commands being sent from ST. :(

ty27386 commented 3 years ago

As of 4/26/21 - stopped working. No 2FA prompts.... alarm.cm app doesn’t even show the commands being sent from ST. :(

I’m having the same issue. Logs in successfully but not showing any coolants being sent.

schwark commented 3 years ago

Looks like reverting to an old version works better - I may have broken things for some people in attempting to fix this 2FA issue. The latest version works for me, but this older version seems to work for more people.

https://github.com/schwark/smartthings-alarmcom/tree/85ffdd4b0b68988697eb9a4532704176e13be0c5

I will look into this further when I have some time.

adrian97c commented 3 years ago

Looks like reverting to an old version works better - I may have broken things for some people in attempting to fix this 2FA issue. The latest version works for me, but this older version seems to work for more people.

https://github.com/schwark/smartthings-alarmcom/tree/85ffdd4b0b68988697eb9a4532704176e13be0c5

I will look into this further when I have some time.

Thanks for the update, I did just try the older version, but both are not working for me. I’ll keep my eye on this thread for the time being thx again for all that you do!

adrian97c commented 3 years ago

Update: I deleted & re-installed using the most recent codes... (old code froze my switches) the switches now toggle correctly, but 2 issues remain: 1) they don’t reach alarmcom 2) ST can’t see them when creating Scenes/Automations.

puzantyac commented 3 years ago

Any update on making this to work

adamyoung3 commented 3 years ago

Here's a working github (UVJustin) for alarm.com integration with 2FA enabled (uses cookie). Per the issues comment it seems to be working. My Schwark setup is still working so i am hesitant to enable 2fa. Maybe Schwark or someone here can figure out how the 2fa cookie works and bring it over. https://github.com/uvjustin/alarmdotcom

adrian97c commented 3 years ago

My 2FA was nev

Here's a working github (UVJustin) for alarm.com integration with 2FA enabled (uses cookie). Per the issues comment it seems to be working. My Schwark setup is still working so i am hesitant to enable 2fa. Maybe Schwark or someone here can figure out how the 2fa cookie works and bring it over. https://github.com/uvjustin/alarmdotcom

My 2FA was never enabled. Yet the Schwark build stopped working. Each morning I accidentally trigger alarm, I can’t wait for a working fix. I don’t want to enable 2FA at this time.

mathieurousseau commented 3 years ago

From what I am seeing, alarm.com website is slow, it takes 17s to activate the alarm from the official alarm.com website. Schwark smartapp calls the website, but limitation from smarthings platform is a timeout of 10s.

So basically, as alarm.com takes more that 10s to respond, call fails.

so either alarm.com improve their site or schwark need to change his code and try to use experimental async calls... which would require some refactoring.

schwark commented 2 years ago

https://community.smartthings.com/t/st-edge-smartthings-alarm-com-integration/246934