L0phtcrack 7 will be released as open source
twitter.com
twitter.com
A bit before L0pht was founded, one of the open source crackers for Unix passwords was called Crack.
https://en.wikipedia.org/wiki/Crack_(password_software)
At the time, SunOS was distributing the encrypted passwords for an organization over the LAN via YP (aka NIS). I worked for a company with lots of Suns and other Unix workstations, and I'd gotten almost all of the non-Suns also configured to use and trust the YP maps. (The goal was to reduce friction to engineering work, and we weren't directly connected to the Internet.) So I ran my site's passwords through Crack one evening, and it easily got many people's passwords. (I don't remember how many SPARCstations I threw at it, but it was probably only a few, less than 100 MIPS total.)
Things like running Crack were within the scope of the sysadmin side of my job at time, I dutifully reported the concerning results to the head sysadmin, engineers were asked to change weak passwords, and all was good.
Some people who ran Crack at some other companies, however, got in big trouble, when there was ambiguity or misunderstanding, about their authority or intent. Besides all the mischief-or-worse uses of Crack that presumably went on. (Disclosure: One of the net.famous people who got a career footnote by running Crack happened to be an acquaintance for a while, years later; I didn't ask them about what must've been a pretty upsetting event, and I just now read on Wikipedia that their case was expunged in the end.)
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.
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.
Some links: https://en.m.wikipedia.org/wiki/Proof_of_knowledge https://en.m.wikipedia.org/wiki/Digital_signature https://en.m.wikipedia.org/wiki/Secure_Remote_Password_proto...
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.
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.
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. :)
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.
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".
0: https://alecmuffett.com/alecm/software/crack/
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.")
If anyone's considering running LophtCrack/JackTheRipper on their work password hashes, make 100% sure your boss know and hasn't told you not to. (Ideally, do not do it without in-writing approval from your manager.)
L0phtCrack -> https://en.wikipedia.org/wiki/L0phtCrack
(And also thanks to people like those that run the Internet Archive who make history accessible when original pages bitrot.)
I would call that real hacking but kiddies at the time had a lot of fun creating problems to the new netizens.
Due to the GPU shortage they have been unable to produce products and are in bankruptcy. Terahash defaulted in a payment and the ownership reverted back to L0pht.
We never did anything stupid or caused damage. I think the relationship was somewhat based on an implicit statement of mutual trust.
On the one hand, the administration punished me and one of my friends with something like six months of detentions.
On the other hand, the IT admin asked us to do it again, but write him up a proper report. Basically gave us the authority to do whatever we wanted, and encouraged us that it could be a career, if we did things the right way.
I think that trust and encouragement went a long way to influencing my career path.
It's sad that so many schools in the US seem to have this attitude of "YOU DID SOMETHING WRONG AND MUST BE PUNISHED!!!" instead of actually using it as a teachable moment and encouraging someone who has demonstrated competency with tech to pursue that, given the chances of it leading to a lucrative career.
Imagine if a kid broke the technical rules of the gym and made a dozen 3-point basketball shots in a row -- I'd bet the gym teacher would tell the basketball coach about it instead of writing the kid up. Why can't we do the same for tech?
I received in school suspension for hacking, and I feel like that taught me just the right amount of discipline. I had basically written a boot disk that created c:\autoexec.bat that executed coldboot.com, which was a dos program that immediately rebooted the computer. I then booted all the computer lab machines off that disk. Three days stuck in a boring quiet room with students I had never been around before. Very enlightening.
This was back when we used to see who carried the coolest looking floppies around. Mine was unlabeled black with a black plastic dust cover. My buddy was a rebel and always took the dust covers off his blood red disks.
I am not aware of a better underlying cracking tool than Hashcat.
The challenge for many organizations is putting together the hardware, and maintaining workflows between staff turnover to make effective use of Hashcat.
There is a fair amount of devops and real technique to successful plan design. This is commonly handled through custom scripting and work at the command line.
For distributed hashing you now have networking complexity.
Throw in that some organizations require this work to be done on site in airgapped rooms and you have a market for fully supported turnkey password cracking IT and frontend workflows.
Source: I worked on Forge, a password cracking workflow that leveraged Hashcat for a couple of years.
I got a break quickly (they had used a date as the password) - before I went to stage to stage 2 and used the 20 or so development sun boxes we had over night.