Is there any advantage to splitting a password?

Question

I've been reading about the LANMAN (LM) hash and I'm curious about a particular part of the algorithm.

The LM hash is computed as follows:

1. The user’s ASCII password is converted to uppercase.
2. This password is null-padded to 14 bytes.
3. The 14-byte password is split into two 7-byte halves.
4. These values are used to create two DES keys, one from each 7-byte half.
5. Each of the two keys is used to DES-encrypt the constant ASCII string "KGS!@#$%", resulting in two 8-byte cipher-text values.
6. These two cipher-text values are concatenated to form a 16-byte value, which is the LM hash.

There are a lot of security weaknesses outlined in the linked Wikipedia article and talked about elsewhere, but I'm particularly interested in steps 3 through 6. I'm curious about what led to this design. Is there any real security advantage to splitting a password, encrypting the two halves separately, then combining the two halves to form one hash again? Or is this just an example of "security through obscurity"?

Answer 1

Splitting the password into hashes is not an advantage. It was done for obscure reasons that are no longer relevant today.

The reason that the LanMan hash works this way is because the LanMan hash is built upon DES. DES accepts a 56-bit key. Therefore, it is natural to treat a chunk of 7 bytes as forming a DES key. There's no good way to use DES to hash more than 7 bytes at a time, and we need some way to build a hash for longer passwords out of DES, so the designers of the LanMan hash decided to split the password into two halves.

Today, we'd never build a password hash this way. We'd just use Bcrypt, Scrypt, PBKDF2, or some equivalent -- or we'd build something similar based upon existing primitives, like SHA256. But at the time, Bcrypt, Scrypt, SHA256, etc., didn't exist, opening up the opportunity for the LanMan designers to make this kind of devastating error.

By modern standards, the LanMan hash is a crummy design. There are many many attacks on it. It's very weak. Nobody should use the LanMan hash today if they can possibly avoid it. (As others have pointed out, its security is crummy even by the standards of the time. A fair point.)

Answer 2

Splitting the password is a weakness, not an advantage. It allows breaking each password half independently. Beginning with ASCII characters (codes from 32 to 126, inclusive), then removing the lowercase letters, you end up with 127-32-26 = 69 possible characters in the password alphabet. This leads to 69⁷ possible halves, which is somewhat below 2⁴³. In other words, this is highly tractable through brute force. You do not even need a dictionary.

This is not security through obscurity. This is insecurity through incompetence.

Edit: "highly tractable with brute force" also opens the road for various optimizations. Note that LanMan is not salted, thus precomputed tables can be efficient (you pay the cost of table building once, then you attack several half-passwords -- it is actually worth it even for a single password, since one password is two half-passwords). In 2003, Philippe Oechslin published an improved time-memory trade-off (it is the article in which he coined the term "rainbow table") and computed tables for cracking LanMan passwords. He restricted himself to alphanumeric passwords (letters and digits, but no special signs), thus a space of 2³⁷. The cumulative size of the tables would then be 1.4 GB, with cracking efficiency of 99.9%, and attack time under one minute.

With a 2⁴³ space, i.e. 64 times larger, table size and attack time both rise by a factor 16 (that's 64^2/3), so we are talking about 23 GB or so (that's not much for today's disks) and a 15-minute attack. Actually, the attack would be faster than that, because the bottleneck is lookups on the hard-disk, and the smart attacker will use a SSD which can do lookups 50 times faster than a mechanical hard-disk (a 32 GB SSD costs less than 70$...). The table-building effort (a one-time expenditure) could take a few weeks on a single PC, or a few days on any decent cloud, so it is rather cheap.

Apparently, such tables already exist...

Answer 3

Just because something is more complex does not necesarily make it more secure. I ran a password cracker on my windows box and it appeared to break the passwords up into 8 character strings, and it broke each string independantly of the other string, making the process go extremely quickly.

So from a practical standpoint splitting a password is not beneficial, and @Thomas already covered why it is not beneficial mathmatically.