[EAS] Password Cracking Basics

[John Willkie]

Great comments, Alex and Dave.
 
I have a few nits to pick.
 
1.  I should have said as part of a "defense in depth" approach that you provide people with username/password combinations that give them the lowest level of access (user in windows).  I know this is a hassle, because it means that the admin's routine password/username will give them low-level access, but that's a misreading: the admin could have the highest level of access routinely.  If you are the admin, that means that you could be the way "in."
 
2.  Computers running and Windows Update have have about zero code-based intrusions in the last decade. For the most part, vectors in recent years have been Java, Flash, etc.  Nobody's perfect, but the Stuxnet got in because the Iranians don't use legit windows copies and therefore can't use Windows update.  Sony's playstation breach was caused by a never-updated Apache server running unix, and users were actually running SQL queries on their PS devices, which told even small kiddies all they needed to know to exploit three different levels of insecurity..  Stupid is as stupid does.
 
3.  We have to assume that the hackers read the same sources of information as we do, including this list.  Ideally, all security systems should be exposed to the wild, it's just the keys and username/passwords we need to protect.
 
4.  Beware of systems that require you to change the password, and then don't even check to make sure that the new one doesn't contain the old one.  The code to do this test is about 5 lines, and it can be done with (properly) hashed (semi-encrypted) passwords, not just plain text.
 
5.  I specified a metric based on how many accesses a particular machine can take in within a certain period of time.  That's the important metric, not the number of computers that be directed to attack that target.  If your device can only take 10 login attempts per second and there are 100 computers trying that often against the target, legitimate access will be degraded and the hacking attempt will be easily disclosed.  I should also point out that many hosting providers (mine costs $59 per year) will detect this activity and filter out the hackers.  Usually.
 
6. " When your code gets to a few thousand lines, and upgrades happen without cleaning code, then you have problems. Programmers can be (and typically are) lazy. They'll just comment out or leave in older code while just adding new stuff and these are where the exploits come in play."  This is so wrong, on so many levels.  I don't know how to clean code, my codebase is over a million lines.  Upgrades just replace the entire code base, and should be sandboxed.  (I know it's hard to do this in *nix.)  However, if the specification permits the user to use default passwords, then it's not the programmer's fault they didn't code that.  I'm not necessarily totally-up-to-date on programming and coding practices, but even then, everything in this sounds very much like an ignorant slur.  Or, somebody has extensive knowledge of programming practices in a device or organization and has reverse-engineered code. Which would be a violation of a license agreement ...
 
Here's the REAL truth.  Many programmers simply stitch together their projects using open source modules.  Very little open source code is truly secure and only can become so after much investigation, testing and repair.  The source modules might have NEVER been updated.  This program pattern can be improved, but crappy programmers won't do what the manager didn't ask for.  It's the organization and how they motivate programmers that is at fault, not the coder.
 
7.  There is a common misconception that each (or even any) IP port is "bound" to a particular piece of software.  This just isn't the case.  If your transport is not UDP/IP, then the input and output port will almost always be bound to a particular piece of software.  But, that can change in the course of a minute or second.  There is no way to tell.  If the transport is UDP/IP, there is no need to bind ports to software, and there are good reasons (multiple access on the output side) to not so bind the port.  But, this misses the point, since UNBOUND and UNCOMMITTED ports are more dangerous than ports bound to a particular application or service.
 
8.  I could put money down that the method Dave described to crack a computer-based access control list (ACL) on a different computer is not possible to accomplish within any reasonable amount of time, at least as pertains to Windows.  I seem to remember that there are three levels of encryption on the basic windoze ACL.  Each level would need to be cracked.
 
9.  I still maintain that lock-out (as opposed to slow-down periods after repeated unsuccessful login attempts) are a very bad idea that will lead to infuriated, under pressure customers making irate calls to customer support at the worst of times.  How about, after 5 unsuccesful login attempts, a "forgot your password" link comes up that sends a "reset password" message to your registered email account.  And, this one time only, when you reset your password, it can be the same as the existing password you "forgot?"  I forget passwords all the time.  I don't want to be embarrased about that, I want to get into the machine quickly without human interaction.   I tend to think that customers diagnose and fix EAS systems under pressure.
 
John