> At the time, SunOS was distributing the encrypted passwords for an organization over the LAN via YP
Not encrypted, hashed.
Lots of people look at things like this and they erroneously come to the conclusion that the correct fix is to hide the secrets. And that's how you save up more trouble for yourself down the road because sooner or later somebody's going to steal those secrets you were hiding.
The right fix is to not use Shared Secret authentication. If I don't know my users passwords in any form, I can't very well have them stolen from me, and so there isn't anything to "crack".
I've pasted credentials entries from my toy WebAuthn implementation to HN before, I won't waste space doing that again here, but the point of such systems is that you could publish the credentials by which you authenticate users and not make any difference to their security.
I'm sure you know this, but to provide some context for others - this is one of the few spots where ambiguity between [password] encryption and hashing may have played a role.
OP stated they used crack(1) shortly before L0pth was founded. That puts the timeline somewhere between 1989 and 1992. Although salted MD5 passwords had already become a known thing by then, there would have been legacy setups where some of the password database entries were indeed outputs from ancient implementations of crypt(3). Which implies DES.
To this day, if anyone wants to take a look at the crack sources[0], or download a prebuilt package[1], the default mode of operation is "I want to run passwords through crypt(3)". According to crypt(5) manpage, the legacy DES mode is still supported - just look for the string "descrypt".
1: https://packages.debian.org/sid/crack (has a link to "crack-md5" package; description states: "This package provides the runtime files for the crypt() version.")
In modern systems, sure. SunOS shipped with crypt_unix as the only option for many many years, which used the lower bits of the first 8 characters of your password as a 56-bit key. This was then combined with one of 4096 possible salt values and used as a key to DES encrypt a fixed string.
Solaris 9 (I think?) added the option to switch to sunmd5, so at the time OP was probably correct in it being encryption (abet one way) and not a hash function.
There are now two replies in this vein, so I guess it's worth a moment to expand on how it's not encryption it's a hash even though (a variant of) DES is used and you think of DES as being for encryption.
The whole point of encryption is that you can decrypt it, but that's not what's going on here.
Instead the DES block cipher is being used as a poor man's compression function for the hash. A compression function in this context (distinct from "data compression" like Deflate) is a one way function that takes a bunch of bits and spits out fewer bits in a way that means the result isn't at all helpful for determining the inputs.
It's completely normal to use a block cipher for a compression function. This is the essence of the Merkle–Damgård construction familiar from MD5 through to the SHA-2 family. If you were inventing a new high performance cryptographic hash in 2021 you wouldn't do it 'cos it's going to be slower than your competitors, but if you were trying to cobble together a working password hash for early Unix without a PhD in cryptography DES is all you need.
You can do much stupider things with DES in this space. Microsoft owns at least three which I know of, some of them are even still in use in corporate environments. But DES is not encrypting anything in these scenarios, it's a compression function. The problem with all those Microsoft solutions I characterise as "much stupider" isn't DES, although obviously you should stop using DES because it's 2021, but lots of other dumb things they got wrong.
It takes 56 bits in and spits 64 bits out, and is not lossy. You can decrypt it. It doesn't even hit the Wikipedia definition of a hash function by being able to accept a variable length input (I don't think truncating input really fits the spirit).
You are clearly extremely knowledgeable in this field. But I think you are trying to retroactively apply everything we have learned about how to do it correctly to code that was written 30 years ago. :)
On the contrary, it takes a 56-bit key and a 64-bit block and it spits out a 64-bit block, that's your compression function. 120 bits narrowed to 64.
crypt(3) does that 25 times, the key is your password, the initial 64-bit block is all zeroes - the resulting 64-bit block after the 25 iterations is the hash stored in /etc/passwd
It's just a hash. The hash is too small by modern standards, and so you shouldn't use it. But it's still a hash. You cannot in fact decrypt it, which is why L0phtcrack, still, today, doesn't decrypt it.
I mean, sure, if you knew the password and salt (to make the right modified DES, that's what the salt does in crypt(3)), you could therefore generate the key, and decrypt the hash block 25 times in a row to get back all zeroes. But discovering it's always all zeroes isn't the goal here, you can't break into a Unix system by knowing that the initialisation state of the password hash is all zeroes. The goal of something like L0phtcrack is to discover the secret password and the password isn't encrypted, it's hashed.
There's various protocols involving digital signatures or more rarely, zero knowledge proofs where the verifier not only does not know the password but the prover also does not have to reveal it so evesdroppers can't steal it.
This contrasts to the more common method of storing a hashed password (e.g. with argon2 or bcrypt) where the server doesn't store the real password, but still stores something that might be bruteforcible and the users still have to provide the real password to log in.
In addition to webAuthn (aka fido keys), other common examples are ssh and mutual tls (aka client certificates). SRP is another protocol that does this sort of thing.
Not encrypted, hashed.
Lots of people look at things like this and they erroneously come to the conclusion that the correct fix is to hide the secrets. And that's how you save up more trouble for yourself down the road because sooner or later somebody's going to steal those secrets you were hiding.
The right fix is to not use Shared Secret authentication. If I don't know my users passwords in any form, I can't very well have them stolen from me, and so there isn't anything to "crack".
I've pasted credentials entries from my toy WebAuthn implementation to HN before, I won't waste space doing that again here, but the point of such systems is that you could publish the credentials by which you authenticate users and not make any difference to their security.