How does syskey in Windows increase the security in a domain?

Question

I use syskey in windows XP and Windows 7. I've read Microsoft's article but I have questions.

1. How does this solution increase security?
2. What are differences between using Syskey in a client that joins an Active Directory with a certification server vs. a workstation? Does syskey achieve more security if used in a client that joins a domain controller?
3. In windows XP and 7, this command makes a floppy. Are there any way to make a USB removable device? or a wireless device that will allow me to log in with a Bluetooth wave device?

Answer 1

I'll answer only the first question.

If hashed Windows passwords are stored in the clear they are susceptible to two kinds of attack:

• Crack the hashed passwords using brute force. This is can be done because Windows doesn't use a slow password hashing algorithm like PBKDF2 or bcrypt.
• Pass the hashed password to the Windows kernel. This attack is described in this SANS
  paper.

So Windows encrypts the hashed passwords with syskey. The problem is: if syskey is stored on the same machine as the hashed passwords then this doesn't do much - an attacker with access to the (encrypted) hashed passwords most likely also has access to syskey and can decrypt the hashed passwords. Therefore it's important to keep syskey on a separate device such as a removable disk.

Answer 2

Addressing each part in turn:

1) This control protects against the following threat scenario: An attacker gets physical control of the machine's hard disk. They extract the local SAM database, which contains password hashes for the accounts on the machine and brute force them to get the passwords which they use to log onto another machine they do not have physical control of. SYSKEY works by encrypting the local copy of the password hashes and writing the encryption key to a floppy. You provide the floppy with the key on at system boot.

2) Any machine that isn't a domain controller only stores hashes for local accounts in it's SAM database, so it doesn't really change the attack if the client is participating in a domain or not.

3) Apparently SysKey just writes to whatever's been assigned the drive letter A:, so if you force a USB key to use A: in Disk Management, it'll work. The drive must be present and mounted at boot, so you have to use a floppy or USB disk, not a network share or device. You should also store the floppy/USB (and any backups you make of it) separately from the machine, since the threat is that physical control of the machine is lost.

Lastly, in more general terms, you're doing it wrong! You've implemented a control without knowing what it does. Do a proper risk assessment, understand the threat, then select the control.

It's quite likely, for example, that implementing full disk encryption and using strong passwords and tightening physical security on the device will be more than enough to manage the risk of someone carrying out the attack described above.