Mac OS X password hashes

From MacShadows KB

Jump to: navigation, search

Contents

Introduction

The purpose of this article is to enlighten those to the various password hashing schemes used throughout OS X's lifespan by the OS. First we'll start with some info you'll probably want to know if you plan on understanding any of this article (you can skip this if you find the topics familiar).

Hash function

A hash function is an algorithm which, in essence, produces a digital 'fingerprint' of a set length (typically expressed in bits) completely unique to the data input to the function. It is (should be) irreversible. A hash algorithm is considered cryptographically secure if there is no way to replicate the output of the hash function other than either inputting the original input, or doing a brute force search of the keyspace of the hash function.

Hashes

Hashes in this article will refer to the output of a cryptographic hash function given as input a password or passphrase.

Salt

A cryptographic salt is a system or user specific 'unique' value added in with the password/phrase upon hashing. It is typically random, but can be gathered from other information as well (such as GUID, or UID). Salts can be kept secret, or saved with the hashed result. A salt is used so that hashes of the same password do not have the same result, and to make pre-computed dictionary attacks useless.

Collision

A collision is defined when two different inputs to a hash function produce the same output.

Avalanche effect

An excellent avalanche effect is one sign of a very good hash function. Changing a single bit in the input should, with overwhelming probability, significantly (preferably completely) change the output.

Password

Used in user authentication, it is generally a single word, alphanumeric, and preferably 8 or more characters in length. An example would be 'bannanas375'.

Passphrase

Similar to a password, a passphrase is used in user authentication. Unlike passwords, however, it is generally much longer, typically a string of words, hence passphrase. An example would be 'attack_at_dawn1188'.

Authentication

Simply making sure you are who you say you are. Typically there are considered to be three types of authentication:

  1. Something you are (fingerprint, retina, voice)
  2. Something you have (key card, key)
  3. Something you know (passphrase, password)

Computers today primarily focus on number three, though as the technology becomes cheaper and more affordable, you'll probably have options one and two become more available to the average user.

As a side note, it's interesting to consider the comparative security of biometrics or key/keycard versus password/passpharase authentication methods. As many have rightfully pointed out, biometrics and key/keycard authentication are, from an academic point of view, much more secure because they offer much more plentiful, complex and highly random data (as opposed to predictable passwords invented by humans) which make the authentication process itself very sturdy against direct attack (brute-force, forgery, lock-picking ...). But those who see these types of authentication in such and academic light often fail to consider the loss of security surrounding the key itself. It is much easier to steal a key or keycard than to convince someone to divulge their password. It can even be done without the person's knowledge. And more worryingly, with biometrics as it was seen in a recent case in Malaysia (http://news.bbc.co.uk/2/hi/asia-pacific/4396831.stm) your eye/finger/bodypart isn't secure just because it's attached to you. Some bandits have started chopping off the required body parts allowing them complete access to the protected systems. So one must consider if your data is worth a finger?

Here is how a typical user creation/login scenario works on a modern OS. This may not be entirely accurate depending on your OS, but it'll help you get the picture.

  1. Bob creates a user named 'bob', with the passphrase 'bobrules' on Minute OS
  2. Minute OS passes Bob's passphrase through the MD5 hashing algorithm, which outputs (in hex) '242b6ccc18a241583e29ae409319c5b2'
  3. Minute OS then proceeds to put Bob's user and the MD5 hash of Bob's passphrase in it's database
  4. Bob then enters his username and passphrase to login
  5. Minute OS compares his username to those in the database and finds a match
  6. Minute OS then MD5 hashes the passphrase Bob entered when he tried to login, and compares it to the hash of the username that matched Bob's username which was already in the database
  7. If they match, Bob is then logged in, if not, Bob has to restart from step four

Mac OS X Hashing Schemes

Mac OS 10.0 'Puma' - Mac OS 10.2 'Jaguar'

These systems use Unix DES Crypt(3) to hash the password, and store it in Mac OS X's NetInfo database. This scheme has several flaws, most notably are:

  • The crypt(3) algorithm is insecure, and was first used 27 years ago (25 before the release of 10.2 in 2002) in AT&T's Unix System 7.
  • Passwords are not shadowed.
  • crypt truncates the input to 8 characters, so you're pretty much stuck using a password.
  • As previously mentioned, the hash is stored in the NetInfo database, which all users have access to. This allows anyone to access the hash of your password. This is easily done with the following in a shell: 
$ nidump passwd . | grep username

A typical output from this may look like: 

$ sjobs:3dI880QaIz.Wk:501:501::0:0:sjobs:/Users/jobs:/bin/bash
       |----crypt----|
As you can see from the second line, which is not included in the output, but is simply meant as a guide, the hash is 
3dI880QaIz.Wk
.

Jaguar also allowed a user account to be set to allow Windows file sharing compatibility. Upon enabling that option for a user account, the system prompted the user to re-enter their password which was then encrypted again, twice - once for crypt (the OS X password) and once for NTLM (the password hash used to authenticate remote connections via SMB / Windows file sharing.) The NTLM passwords were stored outside the NetInfo database.

Mac OS 10.3 'Panther'

'Panther' takes a different approach than the previous versions, and it was a step in the right direction. Passphrases are no longer hashed with crypt(3), and instead are hashed with SHA1, a US government standard hashing algorithm designed by the NSA, as well as Windows LM (LANMAN), a decently bad idea. In addition to this, passphrases are now shadowed, and stored in: 

/var/db/shadow/hash/

In a file named the GUID (randomly Generated User ID created by the system) of the user, which can be displayed with the command: 

$ niutil -readprop . /users/username generateduid

You can dump the contents of the shadow file using: 

$ sudo cat /var/db/shadow/hash/GUID_FROM_ABOVE > hashfile.txt

You will find 104 hex characters, the first 64 characters is the NTLM hash (32 NT followed by 32 LM), the last 40 are the SHA1 hash.

A few problems arose however...

  • SHA1 is now considered cryptographically insecure, though it is still considered secure enough for most uses.
  • A salt is not used for the SHA1 hash, making a dictionary attack possible.
  • Windows LM is very insecure, and can be broken fairly easily. Attackers may have to guess the rest of the passphrase and/or case depending on each, respectively.

Why would Apple even bother creating a Windows LM hash when it's so insecure? The answer is simple, really: Windows support. It's this that allows one to use the Windows sharing feature of the OS.

Mac OS 10.4 'Tiger'

Once again in 'Tiger', Apple changed the hashing scheme, but decently for the better. The passphrases are shadowed, and located in the same location, but as with Mac OS X 10.2 (Jaguar), the NTLM hash is only generated and stored if you turn Windows sharing on in the Sharing preferences, which is definitely a step up, especially since OSX warns you that your password will be stored in a more insecure manner when you turn Windows sharing on. Apple also salted the SHA1 hashes with a 32 bit salt, which is prefixed to the hash, and if you upgraded from Panther, it creates a 'compatibility' hash from your previous SHA1 password hash. You can dump the hashfile the same manner as a 10.3 hashfile, and on that note, a 10.4 hashfile is layed out like so:

Legend for hashfile
What it says What it means 
NTLM
 LM hash 
SHA1
 Panther compatibility hash if upgraded from Panther. If not, all zeros. 
SaSHA1
 Salted SHA1 hash

Note: There are no new lines in these, they are placed there for readability only. Remove them as necessary. 

NTLMNTLMNTLMNTLMNTLMNTLMNTLMNTLMNTLMNTLMNTLMNTLMNTLMNTLMNTLMNTLM000000000000
000000000000000000000000000000000000SHA1SHA1SHA1SHA1SHA1SHA1SHA1SHA1SHA1SHA1
0000000000000000SaSHA1SaSHA1SaSHA1SaSHA1SaSHA1SaSHA1SaSHA1SaSHA1000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000
000000000000000000000000

Present issues include:

  • The use of NTLM
  • Salt prefixed to the Tiger hash
  • When Windows sharing is turned off, the LM hash remains (probably for practicality purposes)

Suggestions for Improvement

Heres a list of suggestions for improvement of OSX's hashing scheme.

Ditch LM

Ditching LM hashes to me is a sane suggestion. Especially since Vista is going to drop support for it completely.

Apply KDF ideals to authentication

One aspect could be to apply key derivation function ideals, such as key strengthening to OSX's hashing scheme. This would significantly increase the time it takes to generate hash values, thus all but removing one of, if not the most common ways OSX hashes are 'cracked': brute force. This still relies on the user to input a secure (i.e. not dictionary, or short) passphrase.

Use a more secure hash algorithm

I would suggest moving to WHIRLPOOL or SHA512, and using their full output length.

Prefix IV, generate salt

Instead of prefixing the actual salt value, prefix an IV or similar value, and generate the salt by hashing it concatenated to the passphrase, or a similar method.

Use a larger salt value

No matter the input of the hash function, the output will be a set length.

Use iterative hashing

After computing the salt, (if you chose to do so) use iterative hashing as described in 'Secure Applications of Low-Entropy Keys' by J. Kelsey, B. Schneier, C. Hall, and D. Wagner.

Such as (in pseudocode): 

key = hash( password + salt )
for 1 to 65000 do
  key = hash( key )

or 

key = hash( password + salt )
for 1 to 65000 do
  key = hash( salt + key )

This should take about a second to compute, which is enough to slow down attackers, and yet not annoy most users.

References

The knowledge of many, many friends.

Retrieved from "http://www.macshadows.com/kb/index.php?title=Mac_OS_X_password_hashes"

Personal tools
Ads