Category: security

I’m with Keith here [note: in the interests of minimizing duplication, I’ve hacked his post down to the most stinging statements. Go read it yourself if you’re interested in a good discussion of the problem.]

---

A security countermeasure that isn’t all that
…

The password that you just entered went into the user name text box of the login dialog. When you hit enter, you attempted to log into your workstation using your password as the user name and a blank password. Because this login failed it’s logged in the Event Log. Guess what’s in there? Yep, it’s your password!
So in the interest of making your machine more secure, it is actually compromised…

… As Schneier constantly reminds us, security is all about tradeoffs. What do you gain by turning on the DontDisplayLastUserName feature? Given that it only takes effect when you’re logged out, not when your workstation is simply locked, not much! There are an awful lot of people who rarely log out of their machines (me included), and rather lock their workstations instead.
… If a countermeasure makes things harder (and more risky) for legitimate users, and doesn’t provide any real impediment for an attacker, it’s a bad tradeoff.
… I’d suggest picking up a copy of Jesper & Steve’s book, which provides really practical advice for securing Windows. It’ll help prevent these sorts of mistakes in the future!

---

This kind of blind use of security “countermeasures” really bothers me. I used to be a blind follower of security checklists in my early career too, so I can’t say I don’t understand the impulse that drives this sort of behaviour.

Still, I can’t believe that after all these years of people publishing these checklists, and lots of other people using them and seeing the consequences of their use, they still get published and used like this – i.e. ignorant of the consequences.

I get pretty frustrated when I see people take security measures like this and end up shooting themselves in the foot. At best, they’re no further ahead overall. At worst, they’ve taken a giant leap backwards, and made it even *easier* for an attacker to escalate themselves and do some *real* damage to your computing assets.

Damn. I really want this setting to be discarded, just like I want to see the “account lockout” setting retired in favour of a more sophisticated, goal-oriented, actually-accomplishes-what-it-sets-out-to-do countermeasure. I am all in favour of more configurability in a system, to give people more options so they can accomodate special circumstances when required – BUT – when a “special purpose” setting like this actually ends up being used blindly by everyone in unsuitable circumstances, and ends up making things WORSE, well that’s when it’s time to seriously reconsider.

Creating the Saved Password

How often does “DontDisplayLastUserName” actually do something security-useful:

1. Computer boots up
2. Computer is Restarted
3. User logs off

VS. times when it can potentially hurt:

1. User locks computer
2. User places computer on Standby (and computer is set to lock on resume)
3. User places computer in Hibernate mode (and computer is set to lock on resume)
4. Computer goes into Standby or Hibernate according to Power Management configuration (and computer is set to lock on resume)

I don’t have any statistics to back up the opinion I’m about to assert, so I’ll just have to use my own user behaviour as a model and let you decide how often it happens from there:

• I rarely power down my computer:
• perhaps once a week or so because something has leaked too many resources over time (e.g. Virtual Memory, GDI Objects, Handles) and I need to free them up
• perhaps once every couple of weeks because I’ve installed something that includes a kernel-level driver (display, network) or because I’ve installed an update that replaces an in-use system-level file
• I almost never log off my computer – why bother? It’s a single-user machine almost all the time:
• My home desktop is used by my wife or houseguests maybe once a month
• My work notebook is used almost never by anyone else, and if I let them use it, I’ll usually just fire up a fresh browser instance (or RDP client) and let them borrow it while I’m there – I just don’t let people log on to my work computer – no reason to, that I’ve found
• I very frequently (e.g. dozen times a day or more) end up with my work notebook locked:
• anytime I move from the house to the office, I’ll put it in Standby or Hibernate
• I’ll pull it open for a while on the bus to or from work and then Hibernate when I walk off
• anytime I go from my office to a meeting (usually 1-3 per day), I’ll S/H while I carry it around
• anytime I walk away from my notebook, I’ll lock it (Windows-L was a wonderful addition to XP)

Under such circumstances, how often do you think I’d accidentally enter my password in a blanked-out username field? Thankfully, I haven’t had that setting forced on me since I forced it on the domains which I administered in my old job as a sysadmin (i.e. 6+ years ago, before I “saw the light”). So I don’t know how often that’d actually happen now – I have no immediate experience to back it up. But if a smart guy like James gets tripped up by it once in a while, then I’m sure I’m no smarter/more attentive than he is.

Exploiting the Saved Password

OK, so let’s assume that for a significant number of computers configured to not display the last username, the user’s password ends up saved in a Security Event Log entry. That log is only readable by members of BUILTIN\Administrators and any process in the LOCALSYSTEM context on Windows up to and including XP (but can be modified on Windows Server 2003, as per Eric Fitzgerald’s article here).

So what’s the big deal? On systems where both (a) physical access is unavailable (e.g. servers) and (b) all patches have been been applied, the risk of a random attacker who doesn’t already have an Admin-level account of getting an admin-level account is usually pretty small (let’s hope – okay, this is probably asking too much, but let’s just assume for the moment, okay?).

However, on systems where either (a) or (b) is FALSE (e.g. (a) on a desktop or especially notebook computer – physically accessible to many classes of attacker; e.g. (b) on a computer where root-level exploits have not been patched), I caution you strongly that “Do not display last user name” may end up giving an attacker a means to retrieve the user’s logon password IN CLEARTEXT and be able to access any resources to which that user account has been granted access.

EFS/RMS Alert!

If you are using a Windows logon-based encryption technology (e.g. EFS, RMS), then you should be doing everything in your power to make it difficult for a physical attacker to discover or guess the user’s logon password – right?!? So my advice: along with all the other things that I’ve recommended in the past (and continue to recommend), I strongly urge you to NEVER set the “Interactive logon: Do not display last user name” setting on any client PC (desktop, notebook aka Windows 2000, Windows XP) where you believe Windows logon password-based encryption is being used.

Note: I am NOT trying to steer you away from these technologies. What I AM attempting to do is to (a) illustrate one cogent, real-world example of why this “Do not display last user name” setting can be more harm than good to your overall security posture, and (b) emphasize yet another way that attackers could be “assisted” in attacking EFS- or RMS-protected data – and what you can to do prevent that.

So there.