Major Security Flaw - Emailing of Mobile Portal Link

[EyezOnRich]

While we don't see it as a "Major" issue - I personally share the same view as PurdueGuy - we understand that different people have different sensitivities to these sorts of things plus it is handy just to be able to see the mobile link from inside your account.

We have split the "generation" of the mobile link from the "emailing" of the mobile link.

You can now create a mobile login and simply view it or cut and paste it where you will. Once created you then have the option to email it if you wish.

[smyers119]

Thanks

[GrandWizard]

Smyers, I had to ask the mail admins. They said that that mail server should be "advertising" TLS but many times the negotiations fail and go to standard transport. If you have any specific logs to show a failed TLS session you can forward them on to support.

Based on a suggestion in this thread we have made the mobile link available on the portal with the option to email it, well, optionally.

So for those that don't like it being emailed you can cut-and-paste it out of your secure SSL browser session if you so choose.

Thanks to everyone on this thread for the feedback. We are listening.

M

[smyers119]

Wizzard, I couldn't find he email for support on your new home page so here is the proof that your mail server is not offering or using TLS. (The Portal link has already been disabled.

This is the full raw header of the e-mail they send, you can check my mail server i fully support TLS as I admin the server:

Return-Path: <noreply@EYEZ-ON.com>
X-Original-To: steve@myersit.org
Delivered-To: steve@myersit.org
Received: from alerts.eyez-on.com (alerts.eyez-on.com [184.106.215.218])
by mail.myersit.org (Postfix) with SMTP id CEB5884B805B
for <steve@myersit.org>; Sun, 24 Mar 2013 01:35:19 +0300 (MSK)
Received: (qmail 27743 invoked by uid 33); 23 Mar 2013 22:35:19 +0000
Date: 23 Mar 2013 22:35:19 +0000
Message-ID: <20130323223519.27742.qmail@alerts.eyez-on.com>
To: steve@myersit.org
Subject: Mobile Portal Link - For Newer Smartphones and Tablets
From: noreply@EYEZ-ON.com


Mobile Portal Link - For Newer Smartphones and Tablets

https://www.eyez-on.com/EZMOBILE/index. ... 5a3cea5591

And Here is the communication with your server showing that your mail server does not support TLS.

Trying 184.106.215.218...
Connected to alerts.eyez-on.com.
Escape character is '^]'.
220 alerts.eyez-on.com ESMTP
ehlo eyez-on.com
250-alerts.eyez-on.com
250-PIPELINING
250 8BITMIME
quit
221 alerts.eyez-on.com
Connection closed by foreign host.

If your server supported TLS this is what it would look like:

Trying 173.0.52.67...
Connected to mail.myersit.org.
Escape character is '^]'.
220 mail.myersit.org ESMTP Postfix
ehlo myersit.org
250-mail.myersit.org
250-PIPELINING
250-SIZE 10240000
250-VRFY
250-ETRN
250-STARTTLS <---------------TLS
250-AUTH PLAIN LOGIN
250-AUTH=PLAIN LOGIN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN
quit
221 2.0.0 Bye
Connection closed by foreign host.

[GrandWizard]

Ok, I'll forward this along. Just email support@eyezon.com

[blakem]

With regards to the keypad they can see inside, presumably they'd have a very limited amount of time to attempt to enter PINs after accessing your keypad before the alarm sounds. With your system exposed via the internet, they can use a script to try PINs in an automated manner. They could even spend days trying to guess you PIN without worrying about triggering the alarm or even you knowing they are trying to figure out your PIN.

No, you can't do that. On DSC systems, for example, after a number of unsuccessful attempts to enter a code the panel enters "Keypad Lockout". The panel will not accept any more attempts until a 10 minute window has expired. Your also get an Enivsalert every time this happens.

The issue of convenience over security has already been hashed out ad nauseum on the forum. I'll summarize; You can either choose to use the mobile link for quick access to your account, or log in normally with your credentials. It is your choice.

We added the quick access hash authentication method a couple of years ago because of overwhelming demand to avoid logging in with username/password on mobile devices.

Thought I would add this true, but only when it is setup. By default DSC initialized the number of attempts and lockout duration values as 0 so you must go into the programming and set them to something other than zero for it to work. For anyone that wants to do this look at programming section 012 in your DSC manual.

I would think someone would want to brute force guess my login password of a dozen characters before guessing a 40 character alpha numeric hash.

[Ouldefauder]

I know I'll catch flak here for distracting from the hash issue at hand, but I'm thinking that if somebody has the skills and access to intercept your email on a relay server, then know how to use the hash data in it to view your system status, then figure out where you live and actually go there... then they're more likely to just steal your credit card online than to break your window in person. So I'd say this is something they might want to look at, but the poster over-hypes the immediate danger a bit.

I agree with you and also think that if you want protection so great as to protect the crown jewels then full time guards are the answer. Most of these systems are for home security and need only prevent or alert you to the unsophisticated burglars who break in the front door, grab what they can and are gone in 10 minutes or less. If they have the ability to grab packets off the internet and disassemble them or capture an E-mail then they are probably not the slightest bit interested in grabbing a few hundred dollars worth of someones personal goods.
Just my opinion.