The standard GNU C distribution comes with a built-in password encryption function, crypt. A seemingly innocent function that uses the long standing DES encryption algorithm. Ignoring the fact that DES has become obsolete over time, the crypt function itself has a glaring problem with it that might not jump out immediately.

A few days ago a friend of mine who’s learning C messaged me to ask me about the crypt function, he was attempting to do this challenge. I hadn’t used the function before so I poked my head into the man pages to check it out. As I was explaining the function to him I spotted something that struck me as odd.

By taking the lowest 7 bits of each of the first eight characters of the key, a 56-bit key is obtained. This 56-bit key is used to encrypt repeatedly a constant string (usually a string consisting of all zeros). The returned value points to the encrypted password

This seems fine, The DES algorithm uses 56 bit keys to encrypt 64 bit blocks of text. It makes sense to take a 56 bit key from the text, and then encrypt the password with it.
However

This 56-bit key is used to encrypt repeatedly a constant string (usually a string consisting of all zeros)

Surely this doesn’t mean what I think it means, if it always encrypts a constant string then does the encryption algorithm only depend on the first 8 characters of the password?

I wrote a quick program to check

#include<unistd.h>
#include<crypt.h>
#include<stdio.h>

int main(){
    char in[200];
    while(gets(in)){
        char * hash = crypt(in, "aa");
        printf("%s\n", hash);
    }
    return 0;
}

Compile with crypt library linked (gcc cryptTest.c -lcrypt)

And sure enough it is true, provided the same salt is supplied, the password only depends on the first 8 characters of the password

Seems to me that this is a potentially very dangerous problem that could arise if someone was not careful when they read the man page for the function.