Security Enhancement Request

[mimitche]

I'd like to request an enhancement (or security fix depending on how you look at it) for the next update to ElkRP:

Can passwords be displayed with ***** instead of in clear text? I'm specifically thinking of the Email and Dynamic DNS tabs in M1XEP Setup section but there are numerous instances where clear text passwords are displayed.

Thanks in advance!
-Mike

 

[Spanky]

I will pass on the request.

Thanks

 

[AutomatedOutlet]

Yes! I second that request. Hard to really have it secure otherwise.

 

[Spanky]

Well, this stirred up somewhat of a heated discussion:

Response from the ELKRP Guru:

In most applications, when you enter a password to LOG IN to a server, password characters are displayed as *s. When LOGGING IN to ElkRP (if enabled) or LOGGING IN to ElkRM or the Virtual Keypad, password characters are shown as *s.



However, when using ElkRP to program passwords in a system, they are not. The reason is simple. Most installers who use ElkRP prefer to see at a glance what is programmed into a system. Replacing the passwords with *s would defeat this. Is it a breach of security? Not really. Consider that the information programmed into a control is very sensitive data. User codes, installer codes, etc. are all sensitive data. One could argue that they too ought to be “hidden.” However, doing so would render ElkRP a fairly useless tool. ElkRP is expected to be used in a secure environment – in an Alarm Installer’s office or, as it turns out, on a homeowner’s PC. Both locations should be considered secure. If you’re worried about someone looking over your shoulder, you shouldn’t be using ElkRP in that location at that time. They’re likely to see not only passwords, but user codes and other sensitive data as well.


________________________

Note: You can turn on access rights for different users to limit what they can see in ELKRP using the Setup Tab.

 

[Steve]

While this doesn't really affect me per se, maybe you could make everyone happy... By your comments, you are telling installers, how they *should* conduct their business or use your tools, perhaps there are some that have their own methods that are different from yours? In order to compromise, what if there was a setting in RP options, like "Hide passwords" and if that was checked, then passwords display as *, if not checked then it works as it is now. That way by default it is no different, but it still allows people like the OP to conduct business the way they want?

Or, by default hide all passwords as * but by each password but a 'show password' button which will display it in clear text?

The first way is probably cleaner, but I guess my point is Elk can easily satisfy both sides and not come across as 'dictatorial' in how the tools should be used?

 

[fcwilt]

Hi,

As a long time (now retired) programmer this has been a pet peeve of mine, the masking of password entry in every case.

When USING a password to get into a system it makes perfect sense to mask it. However when SETTING passwords (as a ELK installer does) I don't think it makes sense to mask them. At this point they are settings that need to be enter and/or verified.

Security is provided by having to use a password to get into the computer in the first place. You can also password protect the ELK database.

Please do not change the current approach.

 

[mimitche]

Here's an example of why this is a security risk:

A security installer installs an Elk based system for a customer who is using a M1XEP. If the passwords were obscured the installer could simply have the customer personally type in their DynDns (for DNS updates) and ISP username and password (for SMTP authentication) when configuring the XEP; this way the installer does not know the customer's personal ISP or DynDNS passwords.

Without the passwords being obscured the security installer now has clear text access to a user's ISP and DynDNS passwords in their database; this is something a security installer should not and does not need access to.

Regards,
Mike

 

[mimitche]

Without the passwords being obscured the security installer now has clear text access to a user's ISP and DynDNS passwords in their database; this is something a security installer should not and does not need access to.

Furthermore these passwords are stored in clear text in the ElkAccts.mdb file- They can easily be viewed with notepad. Let's say you're using multi-operator access with 'Apprentice' granted limited access. The 'Apprentice' user still has physical access to the mdb file so they can still view these customer passwords.

I clearly understand that the database and computer it is hosted on should be kept in a limited access environment and that this mitigates the risk; I'm just trying to think of this from a security first perspective.

 

[AutomatedOutlet]

Response from the ELKRP Guru:

You are the Elk guru!

Note: You can turn on access rights for different users to limit what they can see in ELKRP using the Setup Tab.

Yeah, easy to defeat though. All you need to do is to reinstall RP or access it from a different machine.

In our office, different people have different levels of access to areas or the building based on time, etc. We are fortunate that we have some great people here but I still don't like the idea of running naked.

 

[Steve]

...but I still don't like the idea of running naked.

Yea, that would be scary - especially to your neighbors!

 

[AO-Brandon]

I still don't like the idea of running naked.

 

[123]

I recall watching a documentary about electronic voting systems. One system tabulated all of its results in an unencrypted MDB file and the vendor claimed the data was secure. As mentioned by Mitch, an MDB file can be opened with a text editor and its contents, though slightly garbled, can be read. The voting results were easily modifed without a trace of the alteration. One more 'bug report' for the vendor and another black-eye for electronic voting systems.

The contents of the ELKRP MDB file should be encrypted ... if not, replacing passwords with asterisks is irrelevant.

 

[fcwilt]

Without the passwords being obscured the security installer now has clear text access to a user's ISP and DynDNS passwords in their database; this is something a security installer should not and does not need access to.

Well you do have a point regarding passwords for external services however allowing someone to install your security system entails a good deal of trust in the first place.

I would imagine the installer is going to use his own laptop during installation. He could easily have a key-logger program running. So even if he allows the customer to type in certain items the installer will have access to them.

In any case masking the password is not going to provide any real security. Masking's primary function is to prevent bystanders from seeing your password and even then they can try to watch the keyboard.

Much of what passes for security (at least in this country) is mostly "feel-good" stuff. Liking asking for the numbers on the back of the credit card. If someone has taken your card what good is that going to do?