L0phtcrack 7 will be released as open source(twitter.com)
twitter.com
L0phtcrack 7 will be released as open source
https://twitter.com/dildog/status/1421830165911556099
32 comments
> 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.
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.
> Not encrypted, 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.")
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.")
> Not encrypted, hashed.
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.
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.
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. :)
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.
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 intrigued, do you have more on the subject that you've written that you can link to or articles you'd recommend?
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.
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...
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...
A similar thong got Randal Schwartz a felony conviction (which he eventually got expunged).
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.)
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.)
Don't forget John the Ripper:
https://www.openwall.com/john/
https://www.openwall.com/john/
For context:
L0phtCrack -> https://en.wikipedia.org/wiki/L0phtCrack
DilDog -> https://en.wikipedia.org/wiki/Christien_Rioux
L0phtCrack -> https://en.wikipedia.org/wiki/L0phtCrack
DilDog -> https://en.wikipedia.org/wiki/Christien_Rioux
The cDc were a fun gang of people I think. I was too young to know about them when they were at their top but I read about them just a couple of years later. For example, the Wikipedia page about Christen Rioux that you linked cites a news article from '99 which was entertaining to read: https://web.archive.org/web/20071105094322/http://www.networ...
(And also thanks to people like those that run the Internet Archive who make history accessible when original pages bitrot.)
(And also thanks to people like those that run the Internet Archive who make history accessible when original pages bitrot.)
Those times, end of the 90's, was basically wild west. Many uneducated people fresh on the internet, netbus just recently available, news users would install anything you ask them...
I would call that real hacking but kiddies at the time had a lot of fun creating problems to the new netizens.
I would call that real hacking but kiddies at the time had a lot of fun creating problems to the new netizens.
Also for background, L0phtcrack was sold Terahash (a company that builds password cracking machines for corporate security teams) in April of last year.
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.
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.
Oh wow. I forgot about them! I was just starting out as a teen in the 90s. Went to a couple of 2600 meetings waaay back in the day. That was indeed a wild west scene. I had no idea what I was doing :)
And this is how I got expelled from high school for "hacking"
Should have worked harder at not getting caught. ;)
Was naive and told them everything at the first sign of trouble thinking they'd let it go cause I was only 16.... Boy was that a great life lesson.
That being honest, forthright, and taking responsibility for mistakes, is usually a terrible idea that will just get you fucked over, when you're not dealing with someone you consider a very close friend, was a truth I took a really long time to accept. I still don't like it. But there you go. I was taught, and internalized, something entirely wrong, turns out.
[deleted]
Two of us at school kind of earned the "hacker" badge. Far from being expelled, the teachers expressed admiration for our work and ability to dig into a completely unrelated area to schoolwork.
We never did anything stupid or caused damage. I think the relationship was somewhat based on an implicit statement of mutual trust.
We never did anything stupid or caused damage. I think the relationship was somewhat based on an implicit statement of mutual trust.
When I got caught at school for this one, the approach was really split.
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.
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.
Funny, I had a similar experience -- school suspended me for a week while the IT admin and my father (who also worked in tech) just laughed it off and encouraged me to do more, but in an environment that I owned to experiment on consequence-free.
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?
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?
Expulsion seems incredibly harsh for how “new” a lot of the concepts were, and no real parental ability to teach kids any form of discipline with the technology.
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 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.
Great follow up tweet [0] where he shows built in a trivial to implement license check bypass for people in the scene. From his comments however it seems like it was never uncovered and instead crackers implemented a more complex difficult licensing bypass on pirated versions.
[0] https://twitter.com/dildog/status/1421877460782698500
[0] https://twitter.com/dildog/status/1421877460782698500
I wonder if it's any better than hashcat?
https://github.com/hashcat/hashcat
https://github.com/hashcat/hashcat
Not sure but it appears l0phtcrack uses Hashcat. https://github.com/L0phtCrack/hashcatdll
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 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.
Interesting that the author mentioned John The Ripper" I remember (with a lot of ass covering) using this at British Telecom back in the day - to break into some NT boxes where a customer had lost the passwords.
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.
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.
Quick reminder that PasswordYYYY (eg: Password2021) will pass most "secure" checks (three letter categories, capital, lowercase, numbers). Optionally add a dot or exclamation point - and odds are, in a large organization (assuming you have a list of valid logins) - you'll get a hit..
Unfortunately a lot of these programs are smart enough to figure this out automatically yet the complexity checkers aren't. I think it would be a good idea in an enterprise environment to have a a few cracking servers try to generate the potential new password for a few seconds since a lot of these passwords are easy to derive.
Many companies use 90 day polices as well. So Fall2012! qualifies as a secure password.
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.)