Computing, security, Windows

Historical origins of password policies

There are many things we take for granted in everyday life that are merely the result of historical circumstance, and not very rational when you look closer at them.

One of those things seems to be password policies. subreality posts an insightful ™ comment on Slashdot:

I think a lot of these stupid password policies were the result of Lanman and L0phtcrack.

First, there are two kinds of things that people call “passwords”. #1, a secret phrase that you tell to a remote system to authenticate yourself. #2, a key that has to be cryptographically secure against local attacks.

Traditional Windows NT domains essentially published a Lanman hash of everyone’s password. Lanman had a bizarrely bad hashing scheme: it null-pads your password to 14 characters, then splits it in half to two 7 character passwords. Thus, an attacker gets a local copy of your hash and only has to crack a 7 character long portion of it, which is exactly what L0phtcrack does. Decently good passwords get cracked within hours.

The band-aid attempt to secure this horrible situation was to try to make the most cryptographically secure 7 character password possible. That isn’t a lot of key data to work with so you basically have to have an absurdly line-noised password – and even then it could be cracked given enough time, so NT admins forced changing passwords frequently (which actually doesn’t help, since the attacker just picks up random-guessing on the new hashes as they come out – sooner or later they’ll find one).

So that got enshrined as what a “secure password policy” was supposed to be. Unfortunately, it was designed to protect against an absurdly-bad implementation of scenario #2, when for the most part, your password only needs to be secure in scenario #1, because the hash isn’t published and you can only make a half-dozen attempts to guess it before it gets locked out.

Computing, Windows

Windows 7 UAC

This is a very comprehensive guide to how the user Account Control (UAC) in Windows 7 works.

When UAC is enabled, all user accounts — including Protected Administrator (PA) accounts — run with standard user privileges.

PA accounts can be elevated to Administrator priveleges by clicking OK when prompted. This is the default type for the first account created after installation.

Subsequent accounts created are, by default, standard user accounts. These can be elevated to Administrator privileges by typing a password for an administrative account when prompted.

Applications running with standard user privileges are prevented from sending mouse and keybord events into the windows of elevated applications.

Executables are auto-elevated if they are signed by the “Windows publisher” and are placed in certain protected system directories on the disk. There is also a list of executables that are always auto-elevated.

Folder Virtualization (turned on by default for PA accounts) intercepts writes to files under the %PROGRAMFILES% folder. When non-“Vista aware” executables try to write there, they actually write to the user’s virtual folders. This allows every user to have their own version of, for example, configuration files.
If a “Vista aware” executable try to write to files under %PROGRAMFILES%, without the proper privileges, it simply fails.
Executables are marked as “Vista aware” by a flag in the executable file. This doesn’t actually make them “Vista aware”; it merely signals to the operating system to treat them as such, and turn off backwards compatibility features like Folder Virtualization. Flagging an executable as “Vista aware” without making changes to it may very well cause it to segfault.

References: Microsoft Technet