I've had the opportunity to write a number of password generating functions.  Many of the widely available built-in capabilities do not generate cryptographically secure passwords.  Sadly, they often generate passwords that are rather easily capable of being re-calculated with the right tools or a smart mathematician/cryptographer.  I'm writing this blog post because of some of the work experiences I've had.  I've worked with customers who've had very stringent password policies as well as customers who've had laughable password policies.  Now, whenever I start talking about passwords, someone always stands up and says, "...but passwords are dead thanks to 2-factor authentication/multi-factor authentication."  And while I'd agree with this statement in principle, I can't in practice.  Until all facets of every application and operating system finally kill off the plain-old password, all of the age-old arguments about password complexity, use, and crack-ability should still be of concern.   And given some of the behaviors I've seen customers employ, passwords should be at the fore-front of some organizations' concerns.

An example of a case where passwords are still employed and still a very critical security concern for organizations are the passwords for local administrators.  Why?  ...because this is still an integral part of a hackers' privilege escalation path.  Why?  ...because often times, administrators set this password to the same value on all systems in an office; sometimes all workstation systems; sometimes all Windows platforms in a domain; sometimes all Windows platforms in an enterprise.  And sometimes, they distribute this password in clear-text across the network and/or store the password in a reversibly encrypted fashion (e.g. Group Policy).  Why is this bad?

- Because if you set the same password on all systems in a logical group, then once an attacker knows the password from one system, he effectively owns all of those systems.
- Because if you're sending the password in clear-text, any sniffer on the network can intercept and see the password transiting in clear-text.
- Because if you're setting the password via Group Policy then this means that you are setting the password on a group of machines to the same value and it's stored locally in reversibly encrypted format.

Without sliding much farther off-topic, to fix all of the aforementioned problems with managing the local administrator password, Microsoft recently released the Local Admin Password Solution (LAPS):  https://www.microsoft.com/en-us/download/details.aspx?id=46899 

Note that even if you've disabled/renamed/etc. the built-in administrator account (the S-1-5-*-500), any account with local administrative privileges is still just as important.  Why?  Because it's the "ADMINISTRATOR" role that is important to protect, not what SID the account has.

So... stepping off my soap-box about why passwords are still an important security consideration, lets talk about password complexity and how it relates to password entropy.  For the purpose of this post, the following definitions will be used:

• Password Complexity:  the rules associated with setting passwords to try and guarantee that the passwords used are both difficult-to-crack as well as difficult-to-guess.
• Password Entropy:  the level of chaos or randomness present in a system -- in this case, a string of characters that make up a password.
• Bits of Entropy:  the mathematical measurement, in bits, of how difficult it is to crack a password.

C = Size of Character Set
L = Length of the Password

So there are a couple of really interesting things you might have noticed:

1.  Mathematically, the LENGTH of the password is exponentially more important than the complexity of the character-set used. 
2.  ANY complexity rule, to include defining a required number of numbers, letters, specials, etc., actually increases a password's ability to be cracked.

The following table represents the most commonly used character-sets for re-type-able passwords:

- Numbers:  0-9
- Upper Alphas:  A-Z
- Lower Alphas:  a-z
- Special Characters: ` ~ ! @ # $ % ^ & * ( ) _ + - = { } | [ ] \ : " ; ' < > ? , . /

So the total character size typically ends up being:  10 + 26 + 26 + 32 = 94.  Often times, certain special characters are excluded because they are difficult to re-use.  Sometimes Unicode characters are used but not often in passwords that need to be typed because of the added complexity (e.g. ALT+0156 = œ).

With all of that being said, lets start looking at some combinations of relationships between password complexities, lengths, and resulting password combinations as well as password complexities, lengths, and resulting entropies:

When looking at passwords in this light, it really starts to become clear how much more important the password length is, as opposed to the defined complexity requirements.  To further this point, if you're using passwords with a character set of 10 (only numbers), in order to achieve the same amount of entropy as a character set of 94 (all possible ASCII characters), you only have the double the password's length.  To say it another way, a password that is 16 characters long made up of only numbers provides the same level of difficultly-to-crack as an 8 character password made up of the possible 94 possible characters. 

So hopefully this helped clear up why:

- Password lengths are significantly more important than password complexity requirements
- Password complexity only prevents users from creating easy-to-guess passwords
- Password complexity actually reduces the total number of possible passwords in a key-space
- In theory, the most secure password policy would define a longer-length password with no other complexity requirements with a very large dictionary that consists of all easily-guessable passwords

** NOTE ** - All of the aforementioned assertions assume the passwords are generated by a cryptographically secure algorithm and not stored in a reversible-encrypted or clear-text format.

Without going into too much detail, consider the over-simplified example below as a demonstration of the problem:

$a = 1..10

foreach ($i in $a) {
    if ($i % 2 -eq 0) {
        $i
    } else {
        continue
    }
}

$a | ForEach-Object {
    if ($_ % 2 -eq 0) {
        $_
    } else {
        continue
    }
}

...notice that only one set of multiples of 2 printed out.  What happens in the ForEach-Object loop is that the first number passed into the loop is a 1 and when divided by 2, has a remainder so the ELSE condition applies in the first iteration.  The 'continue' keyword is executed and processing terminates... but why?  Well, ForEach-Object is a CMDLET so when a continue keyword is encountered, the processing scope is the script so processing of the script terminates.  To demonstrate, take another over-simplified example:

Write-Host "Print me to the screen please!"
continue
Write-Host "Print me too please!"

... and only the first phrase prints to the screen.  This is because the processing scope is still the script when the continue keyword is encountered so script processing terminates.  So I can hear you saying, "great, but how do I fix it?"  Well, that's easy -- When using the ForEach-Object cmdlet and you want to emulate the continue keyword behavior in traditional loops, simply use the RETURN keyword instead.  So your loop becomes:

  $a | ForEach-Object {
    if ($_ % 2 -eq 0) {
        $_
    } else {
        return
    }
}

and now behaves as expected and intended.

I told them that the obvious answer was to request an exemption from the screen saver policy and provided documentation on how to do so using an AD Security Group with Security Filtering applied to a GPO but their IT Security team shot it down.  So, I offered the last alternative:  a very easy little PowerShell script that simulates mouse movement to keep the screen from locking due to inactivity.  Once their Network Security team approved the idea for their "less important" networks, I sat down and got to work.

As it turns out, user32.dll has a function that was perfect for my needs:  mouse_event*.  It's function is to "Synthesizes keystrokes, mouse motions, and button clicks".  So all we need to do is figure out how to use it in a PowerShell script.  Well, PowerShell, because it's really just .NET, has this really cool ability to access native Win32 API through a feature called Platform Invocation Services (or 'PInvoke' for short) that allows managed code to access functions native to DLLs that are present on a system.  The key to using a DLL's native functions is knowing the signature of each function you want to invoke.  That's where an incredible resource surfaces:  pinvoke.net.  pinvoke.net is a sort of wiki that documents known DLLs, their associated known functions, and their associated function signatures in a number of different languages.  Looking at the user32, mouse_event function on pinvoke.net, we can see the following two signatures for C#:

With this information and a little easy PowerShell magic, we can easily complete the project!  Please see the attached code:

Download:  [View:~/cfs-file.ashx/__key/communityserver-blogs-components-weblogfiles/00-00-01-04-07/Move_2D00_Mouse.ps1:550:0] ** ,***

Sample Usage: 

Move-Mouse -Secs 10 -LoopInfinite $true

Move-Mouse -XY 10 -Secs 5 -LoopInfinite $true -DisplayPosition $true

* Note that the MSDN page identifies the mouse_event function as deprecated and recommends using SendInput instead. The next version of this script will use the SendInput function instead.

** Note that if you're using software on your computer that takes control of the mouse (e.g. virtualization software while interacting with a guest), this script will not work until you "unlock" the mouse from that application.

*** If you're using the DisplayPosition parameter and are wondering why the X/Y coords are not making the mouse visibly move, it's because mouse_event uses absolute or relative normalized coordinates between 0 and 65535 but the emitted mouse location from the script uses pixels so unless you use a value for the mouse to move that is large enough for it to move an actual pixel, you will not see the mouse actually move.  I prefer it this way so my mouse isn't jumping all over the screen while I'm trying to use it.