Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

The Death Throes of crypt()

CmdrTaco posted more than 10 years ago | from the now-thats-just-too-bad dept.

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

cancel ×

388 comments

Sorry! There are no comments related to the filter you selected.

FP (-1, Troll)

Anonymous Coward | more than 10 years ago | (#7661681)

FP ON TEH SPOKE WERD!!@!`

YUO = TEH FP MASTA ON TEH SPOKE (-1, Offtopic)

Anonymous Coward | more than 10 years ago | (#7661698)

Solaris (4, Insightful)

CrankyFool (680025) | more than 10 years ago | (#7661686)

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

Re:Solaris (-1, Flamebait)

Anonymous Coward | more than 10 years ago | (#7661790)

I wonder if CrankeyFool will stop being an annoyingly fagotry asshat.

Please inform me when the matter is solved.

Perhaps not (5, Informative)

AKAImBatman (238306) | more than 10 years ago | (#7661823)

If I understand the article correctly, they're using serious computer power to develop a database of all passwords and their resulting hashes. In doing so, they can reverse engineer any hash back into a password via a 1 to 1 lookup. The only problem is that the attacker still needs physical access to your password hashes. In other words, this is much more serious for "insider" hacks where a system user wants root control.

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 (2, Informative)

Anonymous Coward | more than 10 years ago | (#7661886)

Shadow passwords work sometimes. Sometimes you can just do "ypcat -k passwd" and get the hashes anyway.

Re:Perhaps not (2, Informative)

AKAImBatman (238306) | more than 10 years ago | (#7661964)

Sometimes you can just do "ypcat -k passwd" and get the hashes anyway.

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 (2, Funny)

iamnotaclown (169747) | more than 10 years ago | (#7661963)

  • If I understand the article correctly, they're using serious computer power to develop a database of all passwords and their resulting hashes.
Look for it on eBay. Coming soon, to a 733t h4x0r near you!

Re:Solaris (4, Informative)

hackstraw (262471) | more than 10 years ago | (#7661826)

Solaris uses PAM, so its trivial to add any kind of authentication method that you want.

You missed the point (1, Interesting)

Anonymous Coward | more than 10 years ago | (#7661975)

The DEFAULT is still DES/crypt. Why not change it?

Re:Solaris (5, Informative)

FireDoctor (11071) | more than 10 years ago | (#7661961)

crypt() is just an interface to an underlying algorithm. In Solaris 9 12/02, there is an option to use Blowfish or MD5:
Enhanced crypt() Function Password encryption protects passwords from being read by intruders. Three strong password encryption modules are now available in the software:

* A version of Blowfish that is compatible with BSD systems

* A version of MD5 that is compatible with BSD and Linux systems

* A stronger version of MD5 that is compatible with other Solaris 9 12/02 systems

Solaris 9 12/02 Release Notes [sun.com]

and System Administration Guide: Security Services [sun.com]

sec0nd p05t (-1)

SpongeScrodSpareCock (717608) | more than 10 years ago | (#7661689)

fucka all to d4 edidurrs wh0 taut d4t the d4 sp0ngem4n [slashdot.org] cood n0t doo 33t. fuck you all. fuck you all. fuck you all.

first (-1, Offtopic)

zsirbena (726592) | more than 10 years ago | (#7661690)

yep!

NO (-1, Offtopic)

Anonymous Coward | more than 10 years ago | (#7661703)

FAILURE I GOT IT

A testament to crypt() (5, Insightful)

grub (11606) | more than 10 years ago | (#7661693)


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() (5, Funny)

Leffe (686621) | more than 10 years ago | (#7661735)

Not many pieces of code will be able to boast that lifespan.

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() (1, Informative)

Anonymous Coward | more than 10 years ago | (#7661777)


No idea what Linux uses but OpenBSD has used Blowfish for ages, those dang visionaries.

Re:A testament to crypt() (1)

Qzukk (229616) | more than 10 years ago | (#7661797)

Depending on your distribution its either crypt or MD5 hashing. Most modern distributions give you a choice: MD5 hash for long password support and security, crypt for supporting legacy applications that don't use standard calls for checking the password in whatever format.

Re:A testament to crypt() (4, Informative)

Carnildo (712617) | more than 10 years ago | (#7661844)

DES is the Digital Encryption Standard. IIRC, it's a 56-bit symmetric-key encryption method, and is considered insecure, as a high-end desktop machine can crack anything encrypted with it in under 24 hours.

Re:A testament to crypt() (0)

Anonymous Coward | more than 10 years ago | (#7661900)

Yes, but he was probably thinking of Triple DES.

Re:A testament to crypt() (2, Informative)

frodo from middle ea (602941) | more than 10 years ago | (#7661871)

OK, I am making a calculate d guess here , but I may be wrong.<P>For any system that takes password inputs from users i.e. the password is entered from outside the system, It really doesn't need to store the password even in encrypted format.<P>
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 progressively delays the next log-in prompt upon match failure to tackel, such a mass brute force attack.<P>
If I am not wrong these days, the password is stored in MD5 hash. And since hash value is theorotically irreversible, it can be stored in plain text. But I guess as an added safety measure, the linux boxes these days store passwords in /etc/shadow rather than /etc/passwd. The shadow file can only be read by root, while other world readable info is in passwd file.

Re:A testament to crypt() (1)

Leffe (686621) | more than 10 years ago | (#7661928)

That sounds very right :)

Re:A testament to crypt() (1)

GammaTau (636807) | more than 10 years ago | (#7661882)

I've also got a question; What is the default/general password encryption scheme used in most GNU/Linux distributions?

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

Directrix1 (157787) | more than 10 years ago | (#7661787)

I think this more shows that reliance on a password being hashed is a futile means of obscuring the source. If a password file is compromised, than it can easily be a short matter of time before it is cracked. The moral of the story, don't let your system be compromised, or at least not the security subsystem.

Re:A testament to crypt() (1)

mahdi13 (660205) | more than 10 years ago | (#7661805)

even though it took 30 years...how many haX0rs do you know that have machine capable of running TeraFLOPs per second?

Re:A testament to crypt() (3, Insightful)

tuffy (10202) | more than 10 years ago | (#7661833)

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

Anonymous Coward | more than 10 years ago | (#7661841)


[tinfoil_hat] I suppose you think Seti@Home is looking for ET? [/tinfoil_hat]

Re:A testament to crypt() (4, Insightful)

Mysticalfruit (533341) | more than 10 years ago | (#7661863)

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() (1, Informative)

Anonymous Coward | more than 10 years ago | (#7661895)


The point is you don't have to compute it anymore, just look up the hash in the database they just made, and find the matching password...

They are pointing out that just because the password is hashed, doesn't mean it is safe if you know the algorithm.

Re:A testament to crypt() (3, Interesting)

jaredmauch (633928) | more than 10 years ago | (#7661970)

lets see, if ms-sql(slammer) and w32.nachi were built to hide passwords and the crypt() result in their icmp messages, and provide a distributed database of this information, how hard would this be?

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.

Re:A testament to crypt() (2)

Lour (76730) | more than 10 years ago | (#7662002)

They dont need a TeraFLOP machine, they just need the 1:1 hash:password file that it generates. So all you need is one haX0r with TeraFLOP access and it seems that we already have one. Then its just a matter of doing a lookup.
The resulting file will be HUGE but with storage as cheap as it is today....

triple crypt lie DES (1)

goombah99 (560566) | more than 10 years ago | (#7661835)

Why not do the same thing for crypt as was done for DES. DES became triple DES. just iterate it 3 times with different salts at each step. Unless there is something insecure about crypt itself, and the sandiego study does not say this, then this should foil any brute force attack like this for another hundered years.

Re:triple crypt lie DES (1)

Zork the Almighty (599344) | more than 10 years ago | (#7661968)

They have a database of all possible hashes. Your scheme would mean that an attacker would have to do three lookups, instead of one.

Re:A testament to crypt() (3, Insightful)

hackstraw (262471) | more than 10 years ago | (#7661873)

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

mattgreen (701203) | more than 10 years ago | (#7661894)

Definitely not grub.

(The bootloader, not the author of the parent comment)

But... (5, Funny)

jchawk (127686) | more than 10 years ago | (#7661704)

Unless they release these hashes out into the wild, the average cracker/hacker does not have access to this type of resource...

Definately cool though for proof of concept!

Re:But... (1)

kfishy (534087) | more than 10 years ago | (#7661733)

They did say however that with $10K of resources, an average cracker should be able to do the same in about a month. Sounds quite serious!

Re:But... (1)

Leffe (686621) | more than 10 years ago | (#7661789)

We real security experts working for the SCO change our passwords at least once every week. The rabid Linux fanboys/SCO haters are actually a little scary, I have to admit.

-- Darl McBride, SCO SPOKESMANN
-- darltehking:edirBcMlarD

WARNING: Do not hack us or our lawyers will have a talk with You.

Re:But... (4, Informative)

UnderScan (470605) | more than 10 years ago | (#7661736)

Read the PDF. The first page tell us that:
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... (1)

*weasel (174362) | more than 10 years ago | (#7661781)

for about 10k anyone should be able to do the same in a few months time, using one uniprocessor machine

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... (1, Informative)

Frymaster (171343) | more than 10 years ago | (#7661819)

so how fast could they do it with ... 20 $500 machines?

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... (3, Interesting)

LilJC (680315) | more than 10 years ago | (#7661741)

It's more than proof of concept. They did this in 80 minutes. Sure, you and I can't do it in 80 minutes, but even if it took us weeks we'd have a shot at cracking something that hadn't yet changed. Maybe not the first time, but eventually someone would get a start on it shortly after it been changed and considered "safe" long enough to be cracked.

Besides, never underestimate the power of distributed computing by MS worms.

ftp site seems slow (5, Funny)

morcheeba (260908) | more than 10 years ago | (#7661782)

They've got the tables on their ftp server, but it seems slashdotted because it's going really slow... my computer says "downloaded 4194304 bytes of 1209462790550 bytes (0.00034%)"

Anyone have a bit torrent for this thing?

Give it some time (2, Insightful)

appleLaserWriter (91994) | more than 10 years ago | (#7661927)

Wait a year or three and this kind of computing power will be available in game consoles in bedrooms across america.

Need more power (4, Funny)

pvt_medic (715692) | more than 10 years ago | (#7661706)

80 Minutes? Obviously we just are not using enough power.

Re:Need more power (5, Funny)

grub (11606) | more than 10 years ago | (#7661721)


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

Re:Need more power (0)

Anonymous Coward | more than 10 years ago | (#7661889)

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

Right, and two planes flying from New York to London get there in half the time!
Imagine a Beowulf clus... ;-)

Re:Need more power (0)

Anonymous Coward | more than 10 years ago | (#7661956)

He was being sarcastic about the misuse of the word "power" you numbnuts.

Re:Need more power (2, Funny)

TobiasSodergren (470677) | more than 10 years ago | (#7661930)

I thought it was because of the time zones.. You can start a little earlier in Europe ;)

Just imagine a... (1)

GeekDork (194851) | more than 10 years ago | (#7661801)

... no, I'm not gonna say it!

Need better crypto (0, Interesting)

ObviousGuy (578567) | more than 10 years ago | (#7661708)

There are lots of alternatives to crypt, but none that are as simple and straightforward to use as it. What is needed is an unbreakable crypto scheme that is simple to use.

Re:Need better crypto (2, Troll)

Directrix1 (157787) | more than 10 years ago | (#7661716)

Your name is ObviousGuy for a reason then, huh?

Re:Need better crypto (2, Funny)

Mikey Hawk (730848) | more than 10 years ago | (#7661766)

I think the answer to that question is obvious, guy.

Re:Need better crypto (1)

dbavirt (543160) | more than 10 years ago | (#7661751)

There are drop-in replacements for crypt such as MD5. How are these any less easy to use than crypt? Sure, MD5 strings are a little longer, but still (I'm pretty sure) less than 80 characters.

Re:Need better crypto (4, Informative)

prockcore (543967) | more than 10 years ago | (#7661839)

Sure, MD5 strings are a little longer, but still (I'm pretty sure) less than 80 characters.

md5 strings are 32 characters. And most linux distros use md5 for their shadow files already.

Re:Need better crypto (1, Insightful)

Anonymous Coward | more than 10 years ago | (#7661859)

It's a pity that the human mind can't be emulated using a computer, otherwise one could store the passwords in the mind of a woman, which is both impossible to understand and decrypt. ;)

Re:Need better crypto (0)

Anonymous Coward | more than 10 years ago | (#7661922)

otherwise one could store the passwords in the mind of a woman, which is both impossible to understand and decrypt.

Will the system let you in is all you need to know ...

how about... (0, Redundant)

frodo from middle ea (602941) | more than 10 years ago | (#7661919)

Open Sesame..

Typo? (-1)

Undaar (210056) | more than 10 years ago | (#7661709)

they precomputed 207 billion crypt() hashes

Are you sure that wasn't supposed to read:

they precomputed 207 billion crypt() ashes?

Change of Methods Needed? (5, Interesting)

Erioll (229536) | more than 10 years ago | (#7661725)

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

haxorest (724387) | more than 10 years ago | (#7661747)

Keeping ahead of the crackers is a big concern not only for security of transactions, but for personal privacy as well.

Who are you calling a cracker? You insensitive clod!

Re:Change of Methods Needed? (0)

Anonymous Coward | more than 10 years ago | (#7661757)

RSA is great so far, but how long until 1024 is broken?

About 2^224 times as long. Suffice it to say that it's still reasonably safe, exempting an attack on the algorithm itself, or an extreme advance in computing.

MD5. (1)

DAldredge (2353) | more than 10 years ago | (#7661785)

MD5 is what most modern Linux distros use.

Re:MD5. (1)

Carnildo (712617) | more than 10 years ago | (#7661916)

From personal experience with cracking passwords, I wouldn't consider unmodified MD5 to be very secure. My computer can test 5 million MD5 hashes a second, or the entire 8-character password space in ten months.

Re:Change of Methods Needed? (2, Insightful)

the morgawr (670303) | more than 10 years ago | (#7661796)

I thought I read that MD5 had some problems as well (that's why OpenBSD uses Blowfish). I think it had something to do with the hashes not being evenly and randomly distributed over the possible space. Anyone who knows more about this care to comment?

Re:Change of Methods Needed? (3, Informative)

mellon (7048) | more than 10 years ago | (#7661899)

This does weaken MD5 slightly, but it's still stronger than crypt(). To put it in perspective, MD5 is still widely specified in new protocols - it's not being phased out.

Re:Change of Methods Needed? (4, Insightful)

gorilla (36491) | more than 10 years ago | (#7661815)

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

Re:Change of Methods Needed? (1)

k98sven (324383) | more than 10 years ago | (#7661884)

The increase is sqrt(2), since one of the factors must be within 1 and sqrt(2^keylength).

So 10^67 then.. but it's still a friggin' big number.

Re:Change of Methods Needed? (2, Insightful)

Anml4ixoye (264762) | more than 10 years ago | (#7661831)

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 concept in mind when you started encrypting your data, then you weren't doing your job. Have 576 cracked shouldn't worry you unless you have older encrypted data using that.

You are right that it is a game. To keep information secure, you have to protect it. Because you protected it, people will want to try to unprotect it. Eventually they will, and if one doesn't keep up, you will lose it.

So, we don't need more secure forms of encryption, we just need to review the current ones and use the appropriate encryption scheme for the data trying to be protected.

Re:Change of Methods Needed? (-1, Offtopic)

Anonymous Coward | more than 10 years ago | (#7661848)

Keeping ahead of the crackers? What about keeping ahead of the niggers, and spicks, and chinks/wops/gooks? No need for all the racist comments!

Re:Change of Methods Needed? (2, Interesting)

Anonymous Coward | more than 10 years ago | (#7661875)

The real threat to cryptography as we know it is quantum computing. Barring attacks on the algorithms themselves, most algorithms in use today can easily be scaled to be unbreakable for the rest of the lifetime of this universe. By "normal" computers, that is. Quantum cryptography provides "perfectly" secure transmission of data, so quantum computing's detrimental effect on current cryptographic communication schemes isn't really problematic. The real problem lies in secure storage and digital signing. AFAIK there is no quantum cryptographic scheme for securely storing data, but current schemes are easily broken by quantum computing (once it becomes feasible to use a few thousand qbits).

Re:Change of Methods Needed? (1)

damballah (691477) | more than 10 years ago | (#7661924)

Elliptic curve cryptography will probably be the new standard in PK encryption. The NSA has already invested time and money to it (there was a story here about the NSA buying a license to the technology from a private company). Moreover, it uses less bits than RSA does. It looks very promising.

Re:Change of Methods Needed? (4, Insightful)

AnotherBlackHat (265897) | more than 10 years ago | (#7661984)


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

Mirror. (5, Informative)

themassiah (80330) | more than 10 years ago | (#7661728)

WARNING!! GOATSE LINK!!! MOD PARENT DOWN!! (-1, Flamebait)

Anonymous Coward | more than 10 years ago | (#7661748)

do not click that link!

*_g_o_a_t_s_e_x_*_g_o_a_t_s_e_x_*_g_o_a_t_s_e_x_*_
g_______________________________________________g_ _
o_/_____\_____________\____________/____\_______o_ _
a|_______|_____________\__________|______|______a_ _
t|_______`._____________|_________|_______:_____t_ _
s`________|_____________|________\|_______|_____s_ _
e_\_______|_/_______/__\\\___--___\\_______:____e_ _
x__\______\/____--~~__________~--__|_\_____|____x_ _
*___\______\_-~____________________~-_\____|____*_ _
g____\______\_________.--------.______\|___|____g_ _
o______\_____\______//_________(_(__>__\___|____o_ _
a_______\___.__C____)_________(_(____>__|__/____a_ _
t_______/\_|___C_____)/_TOSS_\_(_____>__|_/_____t_ _
s______/_/\|___C_____)___MY__|__(___>___/__\____s_ _
e_____|___(____C_____)\SALAD!/__//__/_/_____\___e_ _
x_____|____\__|_____\\_________//_(__/_______|__x_ _
*____|_\____\____)___`----___--'_____________|__*_ _
g____|__\______________\_______/____________/_|_g_ _
o___|______________/____|_____|__\____________|_o_ _
a___|_____________|____/_______\__\___________|_a_ _
t___|__________/_/____|_________|__\___________|t_ _
s___|_________/_/______\__/\___/____|__________|s_ _
e__|_________/_/________|____|_______|_________|e_ _
x__|__________|_________|____|_______|_________|x_ _
*_g_o_a_t_s_e_x_*_g_o_a_t_s_e_x_*_g_o_a_t_s_e_x_*_


Important Stuff: Please try to keep posts on topic. Try to reply to other people's comments instead of starting new threads. Read other people's messages before posting your own to avoid simply duplicating what has already been said. Use a clear subject that describes what your message is about. Offtopic, Inflammatory, Inappropriate, Illegal, or Offensive comments might be moderated. (You can read everything, even moderated posts, by adjusting your threshold on the User Preferences Page) If you want replies to your comments sent to you, consider logging in or creating an account.

Important Stuff: Please try to keep posts on topic. Try to reply to other people's comments instead of starting new threads. Read other people's messages before posting your own to avoid simply duplicating what has already been said. Use a clear subject that describes what your message is about. Offtopic, Inflammatory, Inappropriate, Illegal, or Offensive comments might be moderated. (You can read everything, even moderated posts, by adjusting your threshold on the User Preferences Page) If you want replies to your comments sent to you, consider logging in or creating an account.

Important Stuff: Please try to keep posts on topic. Try to reply to other people's comments instead of starting new threads. Read other people's messages before posting your own to avoid simply duplicating what has already been said. Use a clear subject that describes what your message is about. Offtopic, Inflammatory, Inappropriate, Illegal, or Offensive comments might be moderated. (You can read everything, even moderated posts, by adjusting your threshold on the User Preferences Page) If you want replies to your comments sent to you, consider logging in or creating an account.

interesting system integration issues (3, Insightful)

jrexilius (520067) | more than 10 years ago | (#7661737)

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.

crypt() not necessarily the crypt algorithm (4, Informative)

peyote (9579) | more than 10 years ago | (#7661753)

Remember that many glibc2 "overloads" crypt() to be able to deal with MD5 hashes. I wonder how many MD5 hashes they can generate...

Re:crypt() not necessarily the crypt algorithm (2, Funny)

Cynicx (96073) | more than 10 years ago | (#7661822)

340282366920938463463374607431768211456 is a rough guestimate [16^32] :-)

The reality is (4, Insightful)

phorm (591458) | more than 10 years ago | (#7661765)

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:The reality is (2, Informative)

MikeCapone (693319) | more than 10 years ago | (#7661912)

How many drones working P2P-style (you create these hashes, I'll create these ones) would it take to equal this supercomputer?

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

Re:The reality is (0)

Anonymous Coward | more than 10 years ago | (#7661988)

Quantum computing. BZZT unless you run a quantum computer you are wasting youre time encrypting in future.

Proof that this was MEANT to happen! :-P (5, Funny)

Wyzard (110714) | more than 10 years ago | (#7661776)

Clearly, crypt() was meant to die: just look at its name!

As Schneier says on the first page of Chapter 1 of "Applied Cryptography",

(If you want to follow the ISO 7498-2 standard, use the terms "encipher" and "decipher". It seems that some cultures find the terms "encrypt" and "decrypt" offensive, as they refer to dead bodies.)

Ironic advice (2, Interesting)

baadfood (690464) | more than 10 years ago | (#7661881)

For a book called Applied Cryptography. Perhaps he should have called it Applied Cipherology. Applied Ciphering? Applied Cipherography? I think ill just stick with "crypt", thanks.

First FAILURE! (-1, Offtopic)

Anonymous Coward | more than 10 years ago | (#7661778)

I just couldn't wait for "Troll Tuesday"!


Oh yeah, I FAIL IT! I FAIL IT good!

Sure, but... (-1, Offtopic)

Anonymous Coward | more than 10 years ago | (#7661780)

but can she swallow?

Deep Throat (0)

Anonymous Coward | more than 10 years ago | (#7661905)

thats how I read the subject too.

crypt()? (-1, Offtopic)

Anonymous Coward | more than 10 years ago | (#7661794)

Is that where BSD is going to be buried?

Only if you have the crypt string (4, Insightful)

dbavirt (543160) | more than 10 years ago | (#7661824)

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.

Still (5, Interesting)

mugnyte (203225) | more than 10 years ago | (#7661837)

Even so, using a 10 character input of about 72 possible input chars, isn't 207 billion still only like .0000055% of the total search space?

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 (3, Insightful)

Anonymous Coward | more than 10 years ago | (#7661981)

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

Re:Still (3, Interesting)

Detritus (11846) | more than 10 years ago | (#7662006)

You're assuming that the passwords are random. They aren't. Even with rules like a password must include upper-case characters, numerals and punctuation, they are not even close to being random.

Getting there... (1)

Jhan (542783) | more than 10 years ago | (#7661903)

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.

So much for longer passwords being more secure? (3, Interesting)

doormat (63648) | more than 10 years ago | (#7661911)

I remember back in high school I had created a bunch of accounts on my linux box and used some program to try and decipher the passwords. 1-4 charecter passwords were found in 30 minutes (on my blazing-fast-at-the-time 200MHz Pentium 1), 5 charecter passwords took 2 days, 6 charecter passwords took... well, forever more or less. I figured at the time, a 7 charecter password would be sufficient forever (at least for my life time), but I guess not. Now I use 10 charecter passwords for most of my stuff... Do I need to move to 15 charecters? A passphrase instead of a password?

Re:So much for longer passwords being more secure? (1)

MikeCapone (693319) | more than 10 years ago | (#7661943)

Now I use 10 charecter passwords for most of my stuff... Do I need to move to 15 charecters? A passphrase instead of a password?

I'm not expert, but it seems that the problem is that the actual password can be substituted by the hash of said password.

Usually it is easier to find the password than the hash, but with such brute-force available... Well, the lenght of your password may be irrelevant.

I may be misunderstanding the situation, though. Somebody correct me if I'm wrong.

Too Late (5, Funny)

sirReal.83. (671912) | more than 10 years ago | (#7661934)

I've already rooted all your boxen and converted them to a worldwide Beowulf cluster.

Time to crack some pr0n passwords...

they fear the /. effect (3, Funny)

PxT (26449) | more than 10 years ago | (#7661938)

Heheh... the paper actually talks about them putting a searchable front-end to the results online but then says they decided not to, in part due to the "dreaded 'slash-dot' effect". Nice.

But who DIDN'T see this coming? (1, Interesting)

Anonymous Coward | more than 10 years ago | (#7661939)

Passwords limited to 8 characters. Salts limited to 2 characters. Not exactly a lot of combinations to complicate the brute-force attack now, are there?

The moral to this story is: SHA-1.

Why bother with the force... (0, Offtopic)

bunhed (208100) | more than 10 years ago | (#7661974)

when you have access to the brute. Sheesh!

How are they storing the results? (1, Funny)

Anonymous Coward | more than 10 years ago | (#7661976)

And now the important question,
are they storing it in MySQL or Postgres???

Only 50 million passwords (4, Insightful)

vondo (303621) | more than 10 years ago | (#7661986)

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.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>