The Death Throes of crypt() 388
dex writes "Tom Perrine and Devin Kowatch of the San Diego Supercomputer Center have issued "Teracrack:
Password cracking using TeraFLOP and PetaByte Resources" (PDF, HTML version via Google). Using SDSC's
prodigious computing facilities, they precomputed 207 billion crypt() hashes in
80 minutes."
Solaris (Score:5, Insightful)
Perhaps not (Score:5, Informative)
Correct me if I'm wrong, but wasn't the point of moving the hashes from passwd to another root protected file (like "master.passwd") to prevent this sort of problem?
Re:Perhaps not (Score:2, Informative)
Re:Perhaps not (Score:3, Informative)
Just tried it on my Solaris box. I received the error "the domainname hasn't been set on this machine." A security flaw in NIS domains perhaps? That would certainly make the "insider" problem far worse.
Re:Perhaps not (Score:3, Informative)
Not unless your actually not using shadow passwords at all...
'ypcat shadow' might do it but nobody with any ounce of sanity would put the shadow file on NIS. I use kerberos auth for the passwords and NIS for the rest of the stuff, which works fine... then again I'm behind a nice tight firewall.
Re:Perhaps not (Score:3, Funny)
on OS X (Score:4, Interesting)
nidump passwd
In Panther (10.3+) it will not show the hashes, and I believe a different algorythm is used anyway.
W
Re:on OS X (Score:4, Informative)
In Panther (10.3+) it will not show the hashes, and I believe a different algorythm is used anyway.
In 10.3, the netinfo entries contain a reference to a file and this file contains the hashed password. Of course, the file is readable only by root. I was pretty vocal about this problem so I'm glad to see it fixed. Each user has their hash stored in a separate file, which I guess could be useful. At least it cuts down on pointless parsing.
The hash algorithm used is apparently MD5, but they don't store the hashes in the usual textual MD5 representation. I guess they really hate parsing.
Even more fun was if you used netinfo for network authentication, all hashes for all users on the network were available to the world, not just authenticated users. This meant you had to restrict access to your netinfo server to an IP range to avoid advertising your hashes to the Internet. Thankfully they started deprecating netinfo network authentication in 10.2, but this was recommended practice with 10.1 Server.
Re:Perhaps not (Score:5, Informative)
By moving to a hash like MD5, you can use a much larger "salt". This makes pre-encrypted dictionaries infeasible. Current crypt()-based scemes use a mere 12 bits of salt. A more advanced hash lets you use any length salt you'd like (though anything longer than the hash size is worthless).
Quick primer for those wondering what "salt" is. UNIX stores not only your encryped password, but also a 12-bit salt. The salt is essentially part of your password, which the OS stores in plaintext. Its sole function is to make pre-encrypted password databases difficult. The crypt function is not a true "hash", so UNIX cheats by permuting the encryption boxes using the salt. The effect is the same as adding the salt to a password before hashing it with MD5.
The scheme was developed for the express purpose of defeating attacks like this one. However, 12 bits ain't what it used to be. With only 4096 salts available, pre-encrypted dictionaries are now becoming feasible.
The Solution (TM) is to use a modern hash like MD5, and store a salt which is as long as the hash itself. In essence, this renders encrypted dictionaries worthless -- it's just as easy to brute-force a password from scratch.
Re:Solaris (Score:5, Informative)
Re:You missed the point (Score:4, Informative)
Because Sun guarantees that every piece of software ever written for Solaris will continue to work in new versions. Some would say that they're penalizing the rest of us for those few users still using 10 year old programs. And yet, there's something to be said for "working out of the box".
You're paying your Unix admins anyway. You might as well have them do something more useful than playing NeTrek all day while the system happily chugs along.
Re:You missed the point (Score:4, Interesting)
several datacenters i work with independently only offer solaris 8 so "why aren't you using the latest sun distro's" falls on my deaf ears. the huge body of vendor supplied software which calls for solaris 8 just makes it worse.
nis implementations that pass these crypt values around the network just makes keeping them inaccessible to users a nightmare.
crypt-for-passwords is one of those "standard unix" methodologies that needs to have already died a horrible death. the original title of this topic was hopefully appropriate.
Re:You missed the point (Score:5, Interesting)
nis implementations that pass these crypt values around the network just makes keeping them inaccessible to users a nightmare.
I feel your pain. That's going to be a difficult one to solve though. How does a user authenticate on a network if they can't pass their hash? One could add public key encryption on top of the authentication protocol, but one slip up in key management and the whole deck of cards collapses. After all, how long will it be until we see a worm that uses distributed power to begin generating all possible MD5 hashes? A daunting task to be sure, but certainly not beyond the current state of computing power.
Re:Solaris (Score:5, Informative)
and System Administration Guide: Security Services [sun.com]
Re:Solaris (Score:3, Informative)
I wonder if this functionality would make it feasible to use md5Crypt hashed passwords on a NIS network with Solaris 9 systems. md5Crypt and scalable blowfish (see the OpenBSD blowfish crypt paper [openbsd.com]) are designed so that you can identify the hash function used by looking for specific prefixes in the hashed text.
Obviously NIS should be dead and buried, but in far too many places it is not, yet. It would be nice if it were possible to use a more worthy hash function in conjunction with NIS.
A testament to crypt() (Score:5, Insightful)
Actually with most Unixish systems going to other password formats such as MD5 and Blowfish I'd think that this goes to show that (NSA notwithstanding) crypt() has had a long, healthy existance. Rather than saying 'crypt() is dead' they should be saying 'it took 30ish years but crypt() is at the end of its useful life'.
Not many pieces of code will be able to boast that lifespan.
Re:A testament to crypt() (Score:5, Funny)
10 PRINT "HELLO WORLD"
The most secure piece of code, even on Microsoft(r) Windows(tm) platforms.
I've also got a question; What is the default/general password encryption scheme used in most GNU/Linux distributions? DES? Is DES an algorithm or a collection or interface or something... I don't know anything
I did write a program that worked exactly as crypt did though, it included certain unspoken functions from -lcrypt, especially one named crypt.
Re:A testament to crypt() (Score:2)
Re:A testament to crypt() (Score:5, Informative)
Re:A testament to crypt() (Score:5, Informative)
1) DES has never been "cracked". It has been brute forced.
2) A single machine would take on the order of 600 to 1200 years to brute force a single 56-bit key. Obviously, this number changes with the method used to brute force and the machine used.
There has never been a machine demonstrated capable of cracking 56-bit DES in under 24 hours. The EFF built a DES Cracker which could search the entire key space in 9 days.
DES is not considered insecure. Many applications would likely benefit from another choice however.
Re:A testament to crypt() (Score:5, Informative)
There has never been a machine demonstrated capable of cracking 56-bit DES in under 24 hours. The EFF built a DES Cracker which could search the entire key space in 9 days.
Naw, the EFF machines was later upgraded, and combined with distributed.net was able to crack a DES encoded message in 22 hours [eff.org]
Re:A testament to crypt() (Score:3, Interesting)
However, according to the article you posted:
Re:A testament to crypt() (Score:3, Informative)
The system merely stores a hash value of the password , when the user enters the password, the sytem generates the hash of the user entered password and compares it with stored hash value. If they match bingo, if not try again. Also the system progressive
Re:A testament to crypt() (Score:3, Informative)
Your not wrong, just not all right
It should be irreversible, but by definition it must be "forwardable". I can take every possible password, hash it, and compare the result. If they match, I have figured out the password without reversing the hash function.
This was always possible by exploit
Re:A testament to crypt() (Score:2)
If I recall correctly, Debian defaults to MD5. The traditional way is offered as an alternative if you need it for compatibility.
Re:A testament to crypt() (Score:5, Funny)
Haha! Now it's a denial of service algorithm! Bet you wish you had
11 END
now, eh?
Re:A testament to crypt() (Score:4, Informative)
3DES is a kludge using the original DES in triplicate because alone it was too easy to brute force the keyspace.
Re:A testament to crypt() (Score:3, Informative)
The designers called it "Rijndael", NIST [nist.gov] gave it the name "AES".
Re:A testament to crypt() (Score:3, Funny)
Re:A testament to crypt() (Score:2)
Re:A testament to crypt() (Score:2)
Re:A testament to crypt() (Score:3, Insightful)
They don't need to own such a machine, only have access to one long enough.
Re:A testament to crypt() (Score:5, Insightful)
In ten years, how many haX0rs will have access to TerFLOP machines?
Answer: Lots...
Re:A testament to crypt() (Score:5, Insightful)
Can be used to DDOS, or to compute.
Re:A testament to crypt() (Score:4, Interesting)
also, if you set aside the cpu costs, and need a few terabytes of disk space to store this data, how much does that cost today? according to pricewatch, you're talkinga bout $266 for (about) 300GB of disk. So for just over $1k, you've got 1TB.
Table 7 comes up with 2.263TB of disk space storage, so maybe i'll need a bit more than $2k just for disk. Calcualate your I/O and crypt()/sec, how long would it take for you to generate them all if you generated a distributed application (eg: setiathome-like) and have them be 'uploaded' to you? Obviously you can't do this on your DSL/cable, and you start to see the network performance issues they mentioned, but if you set up a small cluster of your older PCs in a room, use FE to link them up, you'll have that disk and ethernet card spinning (interrupting that is) at a steady clip trying to fill up your disk.
Make a worm/virus that spreads and distributes work units out to other hosts it's able to infect, and you could probally just keep the database in-memory across a wide set of hosts.
triple crypt lie DES (Score:2)
salt and recursive crypt (Score:3, Insightful)
No its not that simple. If it were just a database lookup then simply increasing the size of the salt a million fold would be all that was neccessary to foil any pre-computed attack. The important point in this article is that they it only takes 80 minutes to compute the crypts given the salt.
thus one way to defeat this is to hide the salt as follows. The attack requires
Re:A testament to crypt() (Score:4, Insightful)
Also, the method of "cracking" crypt() passwords can generate collisons, so the password that worked on one system may not work on another (because of different salts used).
But... (Score:5, Funny)
Definately cool though for proof of concept!
Re:But... (Score:4, Informative)
Using the Blue Horizon supercomputer at the San Diego Supercomputer Center, we found that pre-computing the 207 Billion hashes for over 50 million passwords can be done in about 80 minutes. Further, this result shows that for about $10K anyone should be able to do the same in a few months time, using one uni-processor machine.
Re:But... (Score:2)
so how fast could they do it with 10 1k uniprocessor machines? or 20 $500 machines?
partciularly with an easily segmented problem like this, the most likely 'wild' resource would be @home-ish.
Re:But... (Score:2, Informative)
well, after the week it would take you to get the 20 $500 machines, install all the os's and clustering software and then write yr custom mpi app to do the cracking... you'd have lost the race already.
Re:But... (Score:3, Interesting)
Besides, never underestimate the power of distributed computing by MS worms.
ftp site seems slow (Score:5, Funny)
Anyone have a bit torrent for this thing?
Give it some time (Score:3, Insightful)
Re:But... (Score:2)
-- Darl McBride, SCO SPOKESMANN
-- darltehking:edirBcMlarD
WARNING: Do not hack us or our lawyers will have a talk with You.
Need more power (Score:4, Funny)
Re:Need more power (Score:5, Funny)
Obviously we just are not using enough power.
Yup, if they ran this on the 220-230V systems in Europe this would have taken only 40 minutes.
Change of Methods Needed? (Score:5, Interesting)
In the wake of stories like this, and yesterday's story about RSA-576 being cracked (here [slashdot.org]), is this a message that we need more secure forms of encryption than we already have? RSA is great so far, but how long until 1024 is broken? Or any other schemes, like the MD5 hashing that's used for digital signatures?
Topics that people with lots of credentials behind their names are going to have to solve. Keeping ahead of the crackers is a big concern not only for security of transactions, but for personal privacy as well.
Erioll
Re:Change of Methods Needed? (Score:3, Insightful)
Re:Change of Methods Needed? (Score:4, Informative)
Re:Change of Methods Needed? (Score:5, Insightful)
Just on a poke guess.... (Score:3, Interesting)
576 (asymmetric) / 72 (symmetric) = 8
1024 (asymmetric) / x (symmetric) = 8 => x=128
So I'm guessing it's about 2^(128-72) = ~10^16 times safer. Which should be enough for a while too, but not quite that long.
Kjella
Re:Change of Methods Needed? (Score:5, Informative)
I recall reading somewhere that it takes about ten bits to double the security of a public key, rather than one. I don't know if that's actually true.
Re:Change of Methods Needed? (Score:3, Insightful)
In a word, no.
As was also discussed yesterday, *nothing* is uncrackable, with the exception of correctly used one-time pads.
The key is to put the appropriate level of security with the data you want protected. For example, if you have data you have to keep secret for 2 months, and they can crack it in 6, you can use that. But if you need to keep data, worth millions of dollars, secret for an extended period, then you should review your security.
However, I think that if you didn't start off with the above
Re:Change of Methods Needed? (Score:2, Interesting)
Re:Change of Methods Needed? (Score:5, Insightful)
No, it's a message that if you're still using stuff that was developed in the 1970s, you should consider upgrading to the stuff from two years ago.
-- this is not a
Re:MD5. (Score:3, Insightful)
You're mistaken. If you assume that a 8 character password only has upper and lower letters and numbers there are 218340105584896 possible combinations. That would take your computer about 7 years to test the space completely. If you allow passwords to have punctuation then this increases a lot
Mirror. (Score:5, Informative)
http://home.twcny.rr.com/scooper2/teracrack.pdf [rr.com]
interesting system integration issues (Score:3, Insightful)
Re:interesting system integration issues (Score:5, Informative)
In standard crypt() format, the salt is the first two characters of the hash.
The canonical way hash a password using crypt():
The characters "xo" are chosen at random when the password is first hashed. Note how they are the first two characters of the hash. The canonical way to check if a given password matches a hash is:Note how I use the entire hash as the salt. Only the first two characters of the salt are actually used by crypt(). Actually, only twelve bits from the first two characters are used for the salt: Two different salts resulted in the same hashes: this shows that crypt() does not use the entire 16 bits of the two characters (indeed, not even the entire 14 bits of the characters as US-ASCII). Only twelve bits are in fact used.Also, the entire password is not used: in fact, only the first eight characters of the password are used:
Since slashcode strips un-american characters, I cannot demonstrate the the top bit of each character in the passphrase is discarded.
Now, we can do some math: if 12 bits of salt is used, we have 4096 possible salts (2 ^ 12). If 7 bits of 8 characters are used, we have 7 * 8 = 56 bits of possible password. Thus, we have 2 ^ 56 * 4096 = 295147905179352825856 possible passwords (295 quintillion).
Now, these numbers don't match up with what's reported in the article description (207 billion hashes). It's possible that some combinations of passwords and salts produce identical hashes, but I would never expect nearly this many...time to read the article.
OK, I skimmed the article. They did not cover the entire keyspace of passwords. They only created a list of candidate passwords from a system dictionary using Crack's password generation routines. There are 1425835290 (1.4 billion) times more possible passwords than they tested. If they tried hashing all possible passwords, it would have taken them 217022 years at the rate they're going (80 minutes per 207 billion passwords). The storage of these hashes is out of the question (I don't know my metrics that high :).
Actually, on second thought, I can imagine a compression scheme that could drastically cut down on the storage involved: but this is irrelevant, the CPU time is still overwhelming.
Lesson learned: worry more about the quality of your passwords than the quality of your password hashing algorithm.
[Perhaps I missed something? Anyone care to check my arithmetic?]
crypt() not necessarily the crypt algorithm (Score:4, Informative)
Re:crypt() not necessarily the crypt algorithm (Score:2, Funny)
Re:crypt() not necessarily the crypt algorithm (Score:3, Interesting)
MD5 time trial. Digesting 100000 10000-byte blocks
Digest = 766a2bb5d24bddae466c572bcabca3ee
Time = 18.865835 seconds
Speed = 53005869.601767 bytes/second
So for that sake of this argument, you have a 10,000 character password, and I have a 500 mhz P3 running FreeBSD 5.
If my math checks out below, in 80 minutes you can do 25 million 10,000 character passwords. I assume you have 8bit bytes, and one byte is
The reality is (Score:5, Insightful)
Crypt is already supplantable by many improved techniques, but even if it is used, are they going to make these keys available to the world?
If not, now that it's known a really faster computer can solve then, perhaps the next step in spammy-crackers' arsenal will be to take their virussed drones away from attacking anti-spam sites and focus them at generating crypt or other password solutions? How many drones working P2P-style (you create these hashes, I'll create these ones) would it take to equal this supercomputer?
Re:The reality is (Score:3, Informative)
I believe that what you are refering to is called "distributed computing".
A good example of crypto-key cracking by distributed computing can be found here [distributed.net].
Proof that this was MEANT to happen! :-P (Score:5, Funny)
Clearly, crypt() was meant to die: just look at its name!
As Schneier says on the first page of Chapter 1 of "Applied Cryptography",
Ironic advice (Score:2, Interesting)
Only if you have the crypt string (Score:4, Insightful)
The ability to generate lots of crypt strings only helps you if you have the original crypt string to compare against. Most modern UNIX systems store crypt strings in /etc/shadow which is only readable by root. The crypt string is never passed across the net during most auth sequences. (Certain types of LDAP auth being the exception here.)
The problem occurs if someone manages to break into a machine, achieve root, and pick up the /etc/shadow file. They can now brute-force all the passwords given enough time, and it appears that the amount of time needed is shrinking.
This is a good argument for using different passwords on untrusted boxese and changing your password often.
Re:Only if you have the crypt string (Score:4, Insightful)
This won't "crack" inactive accounts, but it will capture any account where somebody uses a password to log in. On most systems the attacker wouldn't even need to hide this function in an existing pam module, they could just provide a new one with an official sounding name (e.g., "pam_audit") and edit the PAM configuration files.
(N.B., not all access requires passwords. E.g., I prefer using SSH DSA authentication instead of password authentication.)
Still (Score:5, Interesting)
So that 20000 * 80minutes gives ~1% of the space cracked?
2000000 * 80 minutes = 304 years to fully close the space.
With a perfect distribution, the mean of about 150 years seems like a long time.
Someone please check my assumptions here.
Re:Still (Score:3, Insightful)
Re:Still (Score:4, Interesting)
Re:Still (Score:3, Informative)
A hash is a digest of a piece of data, as such there is more than one possible password for every password hash.
207 Billion hashes is a substantial portion of the possible hash values.
No offense meant to the parent poster, you can't know everything and I suppose this is more obscure than a lot of things, but I'm really really surprised this got modded up like it did.
Re:Still (Score:5, Informative)
You are thinking about normal computer science hashes not cryptographic hashes.
207 billion is a very small portion of the possible hash relations.
I worked on a project similar to this, a distributed password cracker.
They calculated 50million passwords and 4096 salts this gives ~207Billion hashes.
There are ~7.32*10^14 possible passwords (quick approximation) with the 4096 possible salts.
That gives ~2.99*10^18 possible hashes.
I think the author of the other post was thinking there would be a lot of collisions.
There are 2^64 possible permutations of the DES 'cipher text' which gives ~1.8*10^19 possible 'cipher text' final state.
This means there are six times as many theoretical hashes as there are actual password hashes.
That and the nature of the DES algorithm would make colusion not very likely.
Anyway back to the point... 207 billion hashes would be 2.07*10^11.
2.07*10^11/2.99*10^18 =
This is NOT a substantial portion of the search space.
-Nick
*cipher text is refering to the initial 64 zeros cipher text used in the DES password encryption.
Getting there... (Score:2)
I may be mistaken, but I thought crypt() used 56 bit DES encryption. They can brute-force 207e9 hashes per 80 minutes, but the total key space is about 72e15 (2^56).
This means that the key space will be exhausted in ((2^56/207e9)*80)/60/24/365.24 years, which is about 52 years.
I do agree that this is still a little too close for comfort. Fortunately no-one I know is still using classic crypt() for password protection.
Re:Getting there... (Score:5, Informative)
Yes, this is a very small part of the total theorectical key space.
But its exactly the part of the space that is most "interesting"; this is the part that will most likely be searched by an attacker AND the part that is most likely to have a real, user-selected password.
The original goal (years ago) was to allow us to verify that our users weren't using passwords that would be likely to be found by an attacker.
Yes, passwords are *supposed* to be stored in shadow files that are not accessible, except by root, but in practice, it is often discovered out in the Real World, especially at larger multi-vendor sites, that user password hashes are copied between machines, stored in databases, and in general available to an attacker who does not yet have root.
These are the same sites that often can't or haven't converted to md5() hashes, as they have older legacy OSes that don't do md5(). Note that even though Sun "supports" md5() hashes, they don't support them everywhere and it certainly isn't seamless. Don't get me started about AIX. Linux and the *BSD folks are way ahead of most of the commercial UNIX variants.
As for the scalability, read the whole paper. We used the largest single machine at SDSC, but its rather dated in terms of crypt() performance. A distributed.net-style project using typical home machines would win, IF you could get a thousand or so people to cooperate.
The Terabytes of storage in a single filesystem didn't hurt in the sort/merge phases either.
Personally, I'm a Kerberos fan
So much for longer passwords being more secure? (Score:4, Interesting)
Re:So much for longer passwords being more secure? (Score:4, Informative)
Re:So much for longer passwords being more secure? (Score:5, Funny)
Too Late (Score:5, Funny)
Time to crack some pr0n passwords...
they fear the /. effect (Score:3, Funny)
Only 50 million passwords (Score:5, Insightful)
Moral of the story: Pick a good password.
That's what I like to see... (Score:5, Funny)
I am going to go convert two of my physical binary decision devices into a cup of coffee.
Storage. (Score:3, Interesting)
Yes, yes, but where did he store them?
/greger
"Physical Binary Decision Device" (Score:3, Funny)
Re:"Physical Binary Decision Device" (Score:3, Funny)
Cheating the Crypto? (Score:3, Interesting)
For example, I was looking at the MySQL tables on a site I run, and realized that my password hash there is the same as on other boxes I have accounts on. For example, 5f4dcc3b5aa765d61d8327deb882cf99 is the MD5 sum of "password," anyone with access to a set of passwords could simply skim through looking for this and other well-known hashes.
In many cases, wouldn't it make a fair amount of sense to use machine-specific algorithms for generating password hashes? It could even be something simple, like taking the hash of "$hostname-$username-$password". You could generate all the hashes you wanted, but if you didn't know my username and the hostname, the hash would end up being different. The end result is that, even though I (insecurely, I know) use the same password (and often, the same username), I would have a different password hash on each machine; you'd have to know all three fields before you could brute-force my password.
Is there something I'm overlooking? This idea seems like it'd work out really well; I can't possibly have just described some revolutionary new idea, though.
Re:Cheating the Crypto? (Score:5, Informative)
The problem mentioned with crypt() is that the $salt value is very small (1.5 bytes), thus making dictionary attacks feasible. If MySQL is not using salt values, then they risk similar attacks.
Just what is being crtiqued? (Score:4, Insightful)
Reading the article there is no way that teracrack is going to deal with a strong password, the hash won't be present in it's table.
Regardless of algorithm, the weak passwords will allways be the first to fall. We can all stop using crypt() and start using md5 hashes, but the same techniques can be applied again, and again the first passwords to fall will be the weak ones.
I hate to sound like a Luddite, but technical problems aren't allways best fixed with more technology. The best use of teracrack that I can see, is the same use that it's predecessor had, to identify weak passwords and identify them to the user and admin to ensure that this core problem is addressed.
That's not how it's done... (Score:3, Insightful)
Think of the children, Moore's children!!!
not a new concept, but a new practical limit (Score:5, Interesting)
I (and probably others, I claim no novelty, only an inventive step
Rather than precompute the entire crypt() space, we precomputed the space for well known words (and combinations of those words with different prefix and suffix), because for any individual word, there are only 32 [I think from memory - 5 bits?] combinations that it can crypt to given the random salt that was possible.
Because of available disk space, we couldn't store the entire precomputed output: so we chose to only store the first N bits of it. This was configurable. I cannot remember the exact figure - sure I could dig the code up out of an old CDROM archive
So the password cracker would then mmap() the couple of gigabyte file, then easily find (or not find) a candidate prefix. If it found the prefix, it ran a few trial crypt()'s to ensure an exact match. In practice, because of the lack of diversity in passwords, there were few false candidate matches: so the password cracker had some extremely large hundreds/millions of equivalent cracks per second as a result of mostly just not finding comparisons, and a few trial runs for succesful targets (I think the running rate of the other two popular crackers at that time was about 100K cracks/second).
Anyway - that was a long time ago - fun and games as a student. I still have the source code
Crypt was in "games" (Score:3, Interesting)
Re:Crypt was in "games" (Score:4, Interesting)
That's because the two items (crypt(1) and crypt(3)) utilize entirely different algorithms. The crypt(3) library is of course your everyday average DES, which as this thread notes, has gotten a bit long in the tooth. The crypt(1) command however was an entirely different algorithm based upon the idea of a rotor machine. It only has a single rotor however, which makes cracking it pretty darned easy, probably _way_ simpler than the original German 3 rotor enigma machine. The implementation that is still distributed in FreeBSD (/usr/src/usr.bin/enigma) is from the Crypt Breaker's Workbench, a near automated cracking utility for this code.
Cracking ordinary DES isn't a game quite yet, but it's certainly not the best choice for a password scheme.
I wrote the MD5 based crypt() for a reason... (Score:5, Informative)
The important properties of a good crypt() algorithm are still:
1. Input password is not length or charset restricted.
2. The algorithm is complex enough to not lend itself easily to hardware implementations (FPGAs etc).
3. The Salt is big enough that precomputing dictionaries is not feasible.
You will notice that apart from #1, these are not quantified, DES-based crypt() fulfilled #2 and #3 back in its days, but no longer does so. In a similar way, some day we will declare my MD5 based password scrambler as failing one or both of those criteria because password scrambling is not a case of finding "the" algorithm and putting a checkmark in the box, it needs to on periodically evaluated and improved every decade or so.
That is why I put the $1$ prefix on my MD5-based crypt(), so that you can update to a better algorithm when you need to. OpenBSD has already added a couple of stronger SHA based algorithms ($2...) and more can be added in the future.
In the absense of any other "IANA" for this, I would appreciate if you would register your "magic strings" with me so we don't have collisions.
If you're still using DES-based crypt(), switch to MD5 based crypt() now. Don't wait any longer, you are already 9 years late (IMO).
It's even "free as in free beer"
Re:I wrote the MD5 based crypt() for a reason... (Score:3, Informative)
Details of the pluggable framework with a policy that allows for automigration on password change are available here: crypt.conf [sun.com] and policy.conf [sun.com]
Solaris source code is NOT needed to add new algorithms all code that uses crypt(3c) should continue
Re:Need better crypto (Score:3, Troll)
Re:Need better crypto (Score:2, Funny)
Re:Need better crypto (Score:3)
Re:Need better crypto (Score:5, Informative)
md5 strings are 32 characters. And most linux distros use md5 for their shadow files already.