[EAS] EAS Zombie Attack

[John Willkie]

> 1. EAS manufacturers (many or most who monitor this list) should:
>
> 1. If not already present, incorporate into their next software update code that nags or requires the user to alter the default factory password(s).
> 2. If not already present, support for complex passwords of at least 20 character length. And a display indicating the relative "strength" of the user's password. And rejection of certain common BAD choices (password, 12345678, station call sign, etc)
> 3. If not already present, provisions to "lock out" an account for a period of time (at least an hour, no more than a day) if there has been more than five sequential failed login attempts. And provision to automatically email the engineer about any such lockouts along with IP addresses.
> 4. If not already present, provides a user configurable option to alter the default IP port numbers for the protocols it responds to. This is useful not only for security reasons, but also the pragmatic issue that commonly used routers won't allow remote access to more than one device with the same port number.
> 5. If not already present, provide a user friendly means to disable protocols not needed by the end user.

I don't make EAS systems, but I do make remotely accessed PSIP generators.  While the above list is well-intentioned, it mostly amounts to "security theater" and not security, or what all vendors should already be doing.  Of course, inside the machine, passwords need to be kept not only "hashed" but "salted" so that "rainbow tables" can't be used to easily and quickly reverse-engineer passwords from hashes.
 
All password systems should start with a default password.  However, most operating systems (even Windoze) permit an administrator to set a password to "must change password at first login."  If this isn't a security feature, the vendor is being foolish and the customer will pay the bill.
 
As for password complexity, please, this is a joke from the 1980s and more security theater.  Nor is there any reason to EVER routinely change passwords.  Change passwords when someone leaves.  But, use passwords that are at least 100 characters long.  Speaking of complexity, imagine how many combinations of values a script kiddie needs to go through to try 52^99 combinations? 
 
As for "lock out" not in this life buddy, you are telling vendors to make it difficult or impossible to log on to a system when you've forgotten the password.  How about sending an email message on each failed login attempt?  How quickly would you change the settings if you got such emails?
 
IP numbers can't easily be changed within a device; this is a function of the router/switch and DHCP.  Putting the ability within a device is a non-starter.  As for being able to change port numbers, this is a can of worms, since the vendor most likely previously worked out with the corporate IT department what ports are permitted.  This is a router/switch/firewall issue and not a device issue.  Permitting users to willy-nilly change port numbers is no substitute for having a good firewall.
 
As for "providing any means to disable protocols not in use." If you have a system that by default enables protocols to communicate with the Internet (or even an Intranet) or exposes ports to either by default, you have described a worthless device that can only be taken outside and bashed into pieces.  If a system runs under a computer operating system, the build should only contain the services and features necessary to run the vendor's applications through their entire life-cycle and no other.  No user should be exposed to any option that could compromise secirity; that's just asking for the ability to create a customer-service nightmare.
 
John Willkie
EtherGuide Systems