Skip to main content
Information Security

Return to Answer

added 583 characters in body
Source Link
user2213
user2213

Both operating systems essentially hash passwords using a variety of techniques (crypt() in default DES mode I think was one of the first to repeatedly apply a hash to make checking hashes slower) - this is critical, as encrypted passwords could be trivially reversed by finding the encryption key. Clearly, in both cases, the security of the entry of the passwords depends on your ability to penetrate highly privileged areas; thereafter, the passwords are hashed and must be cracked using hash reverse techniques such as rainbow tables, which the hash design is built to counter.

Both operating systems essentially hash passwords using a variety of techniques (crypt() in default DES mode I think was one of the first to repeatedly apply a hash to make checking hashes slower) - this is critical, as encrypted passwords could be trivially reversed by finding the encryption key. Clearly, in both cases, the security of the entry of the passwords depends on your ability to penetrate highly privileged areas; thereafter, the passwords are hashed and must be cracked using hash reverse techniques such as rainbow tables, which the hash design is built to counter.

Source Link
user2213
user2213

Windows stores its passwords in what is called the Security Accounts Manager database, or SAM database. This is a file that exists in the registry and access to it is tightly controlled whilst windows is running; however, local administrators who can run processes as NT AUTHORITY\SYSTEM can access it - see where does NT store the SAM database?.

As for the hashes used, they are either the LM or NTLM hash. Various attempts have been made to break NTLM; however, LM is known to be broken, so Vista does not use it by default although earlier versions of Windows do. Microsoft also apparently encrypt the database to make it harder to analyse offline.

The key to password security on operating systems is reducing their chance of intercept, so it is also worth studying who and what can access this. In terms of Windows, LSASS, or Local Security Authority Subsystem Service is responsible for verifying and creating user credentials. Thus, any attempt to hook or replace LSASS is an attempt to grab password input.

In terms of the Login screen it used to be possible to redesign it using GINA DLLS - many people did this to support fingerprint authentication, for example. However, custom GINAs are amongst many things quite hard to write and pose a possible security risk, so Microsoft rebuild that in Vista: see the credential provider framework which removes the custom code 1 level away from the GUI objects, which is much safer (Vista did contain improvements, for all people's criticism).

Now, Linux. It's probably better to start with the architecture of Linux authentication - most modern linux distributions use pluggable authentication modules which can be configured for various databases, remote, local etc. These can be configured to be optional, or mandatory, or "one of many options" if you like. The default pam module validates users whose meta data exists in /etc/passwd (so that any program can query it read-only, for example to find the users' home directory) and the passwords are stored separately in /etc/shadow. Directly from wikipedia (shadow password):

/etc/shadow usually contains the following user information:

  • User login name

  • salt and hashed password OR a status exception value e.g.:

    • $id$salt$encrypted, where $id is the hashing algorithm used (On linux, $1$ stands for MD5, $2$ is Blowfish, $5$ is SHA-256 and $6$ is SHA-512, see the crypt(3) manpage.

    • "NP" or "!" or null - No password, the account has no password.

    • "LK" or "*" - the account is Locked, user will be unable to log-in "!!" - the password has expired

  • Days since epoch of last password change

  • Days until change allowed

  • Days before change required

  • Days warning for expiration

  • Days before account inactive

  • Days since Epoch when account expires

  • Reserved

So as you can see, what you can use for your hashing algorithm on Linux is entirely optional. The security of the /etc/shadow database depends entirely on whether you can become root, since the root user is granted access.