The Death Throes of crypt()

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."

Comments

Solaris

[CrankyFool]

I wonder if this will spur Sunto finally make the default password encryption algorithm on Solaris something other than crypt...

A testament to crypt()

[grub]

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()

[tuffy]

how many haX0rs do you know that have machine capable of running TeraFLOPs per second?

They don't need to own such a machine, only have access to one long enough.

Re:A testament to crypt()

[Mysticalfruit]

Here's the more important question...

In ten years, how many haX0rs will have access to TerFLOP machines?

Answer: Lots...

Re:A testament to crypt()

[hackstraw]

Maybe I'm nop paranoid enough, but I've never been too concerned about the security of people's passwords after root has been compromised, so I don't care what format the hashes are in /etc/shadow.

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).

Re:A testament to crypt()

[MooCows]

Actually, quite a lot of them have it now, in the form of thousands of compromised machines.
Can be used to DDOS, or to compute.

interesting system integration issues

[jrexilius]

This should cause some interesting systems integration issues as crypt has become the defacto standard for cross system authentication and password management. (hash it at your web server, compare it with app server, store it in DB, where it is used by samba to auth winblow users, blah blah, I know these arent exact implementation examples but you get the idea). Just a lot of code or libraries to change to make a system secure.

The reality is

[phorm]

That over time, any encryption alghorythm may be broken by superior computer. 50 years from now, normal computers will put anything we have to shame, and supercomputers will make current ones look like calculators.

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:Change of Methods Needed?

[gorilla]

Remember that every bit approximatly doubles the type to break it. RSA-1024 is about 10^134 times harder to break than RSA-576.

Only if you have the crypt string

[dbavirt]

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

[coyote-san]

How hard do you think it is to write a PAM module that sends off an email with the user name and password?

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.)

Re:Still

[Anonymous Coward]

There isn't a unique hash value for every possible password... that's the way hashes work.

Re:Change of Methods Needed?

[AnotherBlackHat]

is this a message that we need more secure forms of encryption than we already have?

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 .sig

Only 50 million passwords

[vondo]

Those 207 billion hashes come from only 50 million possible passwords. Using only 10 letters (no upper case) and 8 characters gives 100 million passwords. Bumping the letter pool up to 75 (52 letters, numbers, a few symbols) give you 1E15 possible passwords.

Moral of the story: Pick a good password.

Just what is being crtiqued?

[i_r_sensitive]

Sounds more like a stinging indictment of weak passwords than crypt().

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.