×

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!

Cheap GPUs Rendering Strong Passwords Useless

timothy posted more than 2 years ago | from the you-have-8-billion-login-attempts dept.

Security 615

StrongGlad writes with a story at ZDNet describing how it's getting easier to use GPU processing against passwords once considered quite strong. "Take a cheap GPU (like the Radeon HD 5770) and the free GPU-powered password busting tool called 'ighashgpu' and you have yourself a lean, mean password busting machine. How lean and mean? Working against NTLM login passwords, a password of 'fjR8n' can be broken on the CPU in 24 seconds, at a rate of 9.8 million password guesses per second. On the GPU, it takes less than a second at a rate of 3.3 billion passwords per second. Increase the password to 6 characters (pYDbL6), and the CPU takes 1 hour 30 minutes versus only four seconds on the GPU. Go further to 7 characters (fh0GH5h), and the CPU would grind along for 4 days, versus a frankly worrying 17 minutes 30 seconds for the GPU."

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

615 comments

So What? (0)

VVrath (542962) | more than 2 years ago | (#36344738)

Isn't the speed of computation pretty irrelevant if there's a delay built in to the challenge/response routine?

Re:So What? (0)

JAlexoi (1085785) | more than 2 years ago | (#36344790)

If you intercept the hash in HTTP Digest authentication or NTLM token, then there is no need to go through a "challenge/response routine"

Re:So What? (2)

gtvr (1702650) | more than 2 years ago | (#36344796)

This has to be considering that someone has the password file. Even if a remote system responded immediately, there is lag for the transmission. Also the local host isn't doing the computation, the remote host is, in that case. The GPU or local CPU is only doing the computations if you have the password to compare against.
I don't know if I wrote that clearly. In other words, if I try to log on to an NT server, and type the password "abc" then the remote server is doing the hashing, not my local CPU or GPU.

Re:So What? (-1)

Anonymous Coward | more than 2 years ago | (#36344968)

There are more passwords to worry about than network logins douche bag.

Password Plus CAPTCHA helps (3, Insightful)

billstewart (78916) | more than 2 years ago | (#36344990)

8-character passwords were strong enough for Unix thirty years ago, but that was a long time ago in Moore's Law cycles; I've got wristwatches faster than that PDP-11. It's annoying how many systems still seem to use them.

For systems that do passwords interactively, you're not going to get the same brute force speed, but you're still exposed to automated attacks - using a CAPTCHA in addition to the password can help prevent them.

Re:Password Plus CAPTCHA helps (1)

iggymanz (596061) | more than 2 years ago | (#36345130)

no need to change, 8 character using say 100 possible character password that isn't word or same as account name still can't be cracked by brute force attempts. Besides the challenge / response lag, and systems not allowing login for certain time after say 4 unsuccessful attempts, look at the math. That's only five attempts every five minutes or one attempt per minute allowed. That's 100 ^ 8 minutes for all possible combinations, or 10^16 minutes, or 2 x 10 ^ 10 years. The Sun would burn out first.

And? (5, Insightful)

ledow (319597) | more than 2 years ago | (#36344746)

And any system worth its salt (crypto-hashing joke) won't allow that many attempts against any external or internal authenticator and will NEVER expose its password hashes.

Seriously, if someone has your password hash, it's game over anyway and it doesn't matter if it takes 2 weeks or 2 months to guess the passwords. And if they don't, then you shouldn't be letting them try several BILLION attempts at guessing a password anyway.

Re:And? (2, Insightful)

Anonymous Coward | more than 2 years ago | (#36345036)

Whenever a company "loses" a database with passwords, we scorch them for storing plaintext passwords. If hashing is supposed to help, then it has to create a significant barrier. As the processing power required for brute forcing password hashes makes longer and longer passwords insufficient, it should become clear that the age of passwords as the sole authentication is coming to an end.

Re:And? (1)

Fourier404 (1129107) | more than 2 years ago | (#36345126)

Defense in depth. By your line of reasoning, there's no problem storing passwords in cleartext. Although a particular line of defense shouldn't be necessary, doesn't mean you shouldn't worry if it's quickly losing potency. There will always be security vulnerabilities, so for someone, somewhere, it matters, e.g. PSN.

Ha Ha, mine goes to 11 (4, Interesting)

ColdWetDog (752185) | more than 2 years ago | (#36344748)

Go further to 7 characters (fh0GH5h), and the CPU would grind along for 4 days, versus a frankly worrying 17 minutes 30 seconds for the GPU."

OK, so go to 15 characters. Using a password generator I can go as far as I like. Using some sort of password bank program, I can store passwords / phrases of any complexity and use copy and paste, thus having only one strong password to remember.

So, what am I missing? (And lets keep it on topic, folks).

Re:Ha Ha, mine goes to 11 (1)

allo (1728082) | more than 2 years ago | (#36344782)

now we can do two things

1) Guess your password generator, therefore the routines used.
2) brute-force the random-seed, generating passwords with the pseudorandom-sequence started by the brute-forced seed, hashing the paswords, all on the GPU.

now your passwords are still insecure.

I think you need a real random source (as some device counting radioactive decay) to create the passwords in a secure manner.

Re:Ha Ha, mine goes to 11 (1)

ZankerH (1401751) | more than 2 years ago | (#36344826)

I think you need a real random source (as some device counting radioactive decay) to create the passwords in a secure manner.

Done. [fourmilab.ch]

What now?

Re:Ha Ha, mine goes to 11 (1)

Plekto (1018050) | more than 2 years ago | (#36345102)

All you need to do is use a unicode character set and it pretty much kills any local password cracking attempts.

Re:Ha Ha, mine goes to 11 (1)

Joe U (443617) | more than 2 years ago | (#36344866)

Use your generator to make a 100 character password, then cut out chunks of it wherever you feel like and add a number or letter here and there until you have a password near the maximum password length for the site.

You don't need a truly random source to be unpredictable.

Re:Ha Ha, mine goes to 11 (1)

gbjbaanb (229885) | more than 2 years ago | (#36344912)

most of the password generators do have randomisation, usually asking the user to bash the keyboard or jiggle the mouse. How random and/or useful that turns out to be is debatable.

Re:Ha Ha, mine goes to 11 (1)

pauldmartin (2005952) | more than 2 years ago | (#36344934)

Err, no. The password generator likely uses some type of crpytographically secure PRNG as you suggested. This means you really would have to brute force the seed. Now say the seed is 512 bits long. How long will it take your GPU to brute force 2^512 possible combinations? For each bit you add, the difficulty of cracking the password increases by a factor of 2, so cracking a longer password in fact IS beyond the scope of our current computational power and likely will be for some time.

Re:Ha Ha, mine goes to 11 (0)

Anonymous Coward | more than 2 years ago | (#36344972)

I think you need a real random source (as some device counting radioactive decay) to create the passwords in a secure manner.

/dev/random on many systems is a "real" random source that can get environmental noise from certain device drivers.

True random number generator hardware can also be purchased quite cheaply these days, and some server systems come with hardware RNGs already pre-installed.

Brute-forcing a random seed also isn't any faster than brute-forcing the hash itself, unless you're using a much shorter seed than password (some old password generators admittedly just used 32-bits no matter the password length, but new ones tend to ensure that the amount of random bits they seed the algorithm with exceeds the length of passwords, rounded up a bit).

Re:Ha Ha, mine goes to 11 (3, Informative)

Securityemo (1407943) | more than 2 years ago | (#36344828)

Also, password phrases. Most online stuff allows you to type in whole sentences. This + some substitution with special characters according to some personal mnemonic means pretty much unbreakable passwords. And even if it's overkill in a technical sense, I seem to be able to remember passphrases easier than passwords.

Re:Ha Ha, mine goes to 11 (2)

zlogic (892404) | more than 2 years ago | (#36344928)

Password pharses are easier to intercept (and remember) if someone is looking over your shoulder. Even if they skip a character or two they could still guess the word.

Re:Ha Ha, mine goes to 11 (4, Insightful)

node 3 (115640) | more than 2 years ago | (#36345136)

But the number of potential attackers is significantly diminished. And he did mention deliberate character substitution, which helps against that (as well as helping against dictionary attacks).

Re:Ha Ha, mine goes to 11 (2)

JAlexoi (1085785) | more than 2 years ago | (#36344832)

Rent a few Amazon AWS Cluster GPU Instances and your 15 char password is broken for a mere 4 to 8 USD... Get the point?

Re:Ha Ha, mine goes to 11 (5, Informative)

PTBarnum (233319) | more than 2 years ago | (#36345048)

Exponential growth. Get the point?

Using the same scaling as the summary, you can crack 8 characters with about 64 GPU hours, which is about $50 on AWS.

By the time you get to 10 characters, you are talking $700k. 12 characters is into the billions. Of course, I doubt that AWS will scale their fleet to billions of servers just so you can rent it for one hour, so you're going to have to pay to build your own data centers and, for that matter, chip factories.

Re:Ha Ha, mine goes to 11 (0)

Anonymous Coward | more than 2 years ago | (#36344868)

One word:
Ph0g4r3N0t4W0rdButF0g|sC4m3l

Re:Ha Ha, mine goes to 11 (2, Interesting)

alt236_ftw (2007300) | more than 2 years ago | (#36344906)

Single point of failure.

Essentially, you will need to carry a copy of your password bank with you AND the application which opens it at all times to function.
This means that if it gets compromised (your memory stick gets stolen/your dropbox account gets compromised/ etc...) an attacker will only need to guess/bruteforce/dictionary attack/social engineer/look over your shoulder one password and gain access to everything in your wallet.

Its not a bad plan in principle, but only if you keep important passwords outside the wallet just in case it gets compromised. The point of the article is to raise awareness to the fact that passwords take less time to bruteforce these days as GPUs are very well suited for the job.

Also, keep in mind that websites have can limits to what passwords you can use (up to x characters, no symbols, etc...)

And, you cannot copy paste your login password to an OS :)

Re:Ha Ha, mine goes to 11 (0)

Anonymous Coward | more than 2 years ago | (#36345082)

it now means you can access the 200Gb of RAR'ed porn files you got off of 4Chan without visiting all those stupid ad filled websites...

Re:Ha Ha, mine goes to 11 (0)

Anonymous Coward | more than 2 years ago | (#36345140)

OK, so go to 15 characters. Using a password generator I can go as far as I like. [...] So, what am I missing? (And lets keep it on topic, folks)

I think the point is that today already anyone with a fast GPU can apparently brute-force simple passwords, 8 or maybe even 9 characters sounds doable if the article is right. That's a whole lot of passwords you can brute-force seeing that most people don't use 15-character generated passwords for anything.

long passwords (0)

Anonymous Coward | more than 2 years ago | (#36344750)

this is why you use them.

increase the time lag between password tries... (0, Insightful)

Anonymous Coward | more than 2 years ago | (#36344752)

...to 1min/try and it will take up to 3.3billion minutes to guess...

Re:increase the time lag between password tries... (1)

Joce640k (829181) | more than 2 years ago | (#36345008)

Sure, IF we're talking about remote logins.

What about, say, a stolen laptop, how exactly will you enforce "1min/try" there...?

If someone gets your hashed password, you're done (4, Insightful)

homesnatch (1089609) | more than 2 years ago | (#36344760)

It is well known that if someone gets your hashed password, it is as good as cracked. 17 minutes vs 4 minutes is irrelevant.

On a live system, it is quite another story. You can't just remotely try 3.3 Billion passwords per second.. You'll be locked out after 10 attempts or so.

Re:If someone gets your hashed password.. (0, Redundant)

Fenis-Wolf (239374) | more than 2 years ago | (#36344960)

You're aware of course that this is an offline attack? The way it works is you snag a hash as it goes across the wire (via man in the middle, client installed malware, or some other attack) then you take that hash and you calculate on your cracking machine passwords until you reach a password that matches that hash. Then the attacker takes your password and goes and logins with it. The server never sees 'billions passwords per second'.

Re:If someone gets your hashed password.. (1)

Anonymous Coward | more than 2 years ago | (#36345060)

Try reading the post you are replying to...

Re:If someone gets your hashed password, you're do (0)

Anonymous Coward | more than 2 years ago | (#36345116)

It is well known that if someone gets your hashed password, it is as good as cracked. 17 minutes vs 4 minutes is irrelevant.

Yes. Now do that calculation again for a 12 char password.

(I use LastPass. I remember one insanely long password for my vault, and then I have one new 12-18 char long password for each new site)

Dunno if that helps (1)

zero.kalvin (1231372) | more than 2 years ago | (#36344768)

My passwords(for important things like the disk encryption one or my work email) are at least 13~15 characters long, including Upper-Lower cases, numbers and special characters, and no dictionary words. Now I did my part, so how about the people on the server side ?

Re:Dunno if that helps (1)

danielpublic (1920630) | more than 2 years ago | (#36345012)

My passwords(for important things like the disk encryption one or my work email) are at least 13~15 characters long, including Upper-Lower cases, numbers and special characters, and no dictionary words. Now I did my part, so how about the people on the server side ?

I would also like to know, how come/why say sha(2) is not the default instead of md5 and/or why blowfish is not supported by glibc? Long time user of passwordmaker here. Change my masterpassword every year, twentyfive char password where THEY will let me. *adjust tinfoil*

It's time for slower hash functions (1)

Anonymous Coward | more than 2 years ago | (#36344772)

The answer to this kind of attack is to hash passwords using hash functions that take a bit more time to compute.

Re:It's time for slower hash functions (1)

grahamsz (150076) | more than 2 years ago | (#36344924)

Yeah, I was thinking about doing that on my site in light of the gawker crack.

Logins are relatively rare events on the server, so I could do something like 1000 SHA-1's with a salt on each iteration. That'd mean

a) It'd take 1000 times longer to crack (obviously this is a constant war between me and the adversary)
b) If i build my own salting implementation on top of sha-1 I doubt I could end up with anything less secure than SHA1 but hopefully it'll require custom software to actually do the exploit.

Re:It's time for slower hash functions (0)

Anonymous Coward | more than 2 years ago | (#36345124)

If i build my own salting implementation on top of sha-1 I doubt I could end up with anything less secure than SHA1

Thus spake the amateur cryptographer before he created another vulnerability...

Re:It's time for slower hash functions (0)

Anonymous Coward | more than 2 years ago | (#36345108)

is it sufficient to do the hash N times?

What about salting? (2)

TubeSteak (669689) | more than 2 years ago | (#36344784)

Is my five letter password more secure if the salt is 15 characters long?
Or am I misunderstanding the nature of the attack and of hashed passwords?

Re:What about salting? (3, Informative)

mazesc (1922428) | more than 2 years ago | (#36344852)

You are misunderstanding it. Salting only protects from precomputed tables containing (password, hash) entries (rainbow tables) when using a unique salt. I didn't read TFA, but I assume this is a simple brute-force attack. The attacker would just add the salt to each guess, which does not make it any more difficult.

Re:What about salting? (0)

Anonymous Coward | more than 2 years ago | (#36344884)

But what about the case when unique salt is used for each hashed password?

Re:What about salting? (1)

jonbryce (703250) | more than 2 years ago | (#36344958)

The salt is stored in a relatively insecure manner. It needs to be because the system takes the salt, adds it to the password you supply, runs it through the hashing function and compares it with the stored hash.

Re:What about salting? (1)

mazesc (1922428) | more than 2 years ago | (#36345018)

It just protects from precomputation of the hash values of the passwords. If there were no salts then the hash value of a given password would look the same in every database (if the same hash function was used). So if you would precompute a rainbow table, where you store the password next to the hash value of the password, you could attack every database easily in the same way by just comparing the hash values and using the password stored next to it in the rainbow table.
Now, with salting we get a unique hash value even if the password stays the same, rendering precomputation useless. The salt, however, is stored in plaintext next to the hash value: (hash, salt).

This does obviously not keep an attacker from computing the hash value = hash(password + salt) - it just helps against rainbow tables.

If you would still want to precompute a rainbow table the amount of memory needed would make it impractical. With n bit salts you would have to store 2^n entries for each password.

Re:What about salting? (1)

Bogtha (906264) | more than 2 years ago | (#36345070)

You're missing the point. If a unique salt is used for each password, then you have to attack each password individually. If the same salt is used for each password, then when you compute a hash, you can compare it against all the hashes in the database at once.

Unless the attacker is targeting your account specifically, then yes, individually salted passwords help.

Re:What about salting? (1)

Anonymous Coward | more than 2 years ago | (#36344982)

You are misunderstanding it. Salting only protects from precomputed tables containing (password, hash) entries (rainbow tables) when using a unique salt. I didn't read TFA, but I assume this is a simple brute-force attack. The attacker would just add the salt to each guess, which does not make it any more difficult.

Not quite. If the salt is long enough, it will slow down the computation of the hash function and thus slow down the attack. It takes longer to hash a 1megabyte password+hash than a 15 byte password+hash

Re:What about salting? (1)

mazesc (1922428) | more than 2 years ago | (#36345046)

You are right of course, but if you would just store extremely long salts for that reason, it would make more sense to include a time delay between computations. Are such long salts used in practice?

Re:What about salting? (2)

Hermel (958089) | more than 2 years ago | (#36344916)

> Is my five letter password more secure if the salt is 15 characters long?

No. The salt helps against dictionary attacks. Normally, it is different for every user, but not secret. It does not help against brute-force attacks.

What does help, is adding more rounds to your key-derivation function (e.g. PBKDF2). Or choosing a longer password.

"Strong passwords useless"? Hardly... (1)

Pennycook (1296497) | more than 2 years ago | (#36344794)

From TFA: "It gets worse. Throw in a nine-character, mixed-case random password, and while a CPU would take a mind-numbing 43 years to crack this, the GPU would be done in 48 days."

Re:"Strong passwords useless"? Hardly... (2)

JAlexoi (1085785) | more than 2 years ago | (#36344882)

If you're a hacker, my bet is you have at least 10 more friends with recent gaming rigs... And guess what? The problem is embarrassingly parallelizable. 4.8 days for a 9 char password(worst case, btw)

Re:"Strong passwords useless"? Hardly... (0)

Anonymous Coward | more than 2 years ago | (#36345084)

Hold on, I just have to turn off all my bitcoin miners first...

Re:"Strong passwords useless"? Hardly... (1)

Anonymous Coward | more than 2 years ago | (#36344932)

The NSA guy who needs to spend 43 cpu years across a farm of, say, 1000 servers in order
to get a password in half a month probably has to write an application to his boss.

The NSA guy who needs to spend 48 cpu days on the same farm in order to get a password
in a little more than an hour can probably just go ahead.

(And, yes, servers in farms often do have GPUs in order to expose this kind of specialized
performance.)

Who cares? (3, Insightful)

IICV (652597) | more than 2 years ago | (#36344800)

Hooray, you can crack an NTLM [wikipedia.org] password in like five seconds! Too bad Windows has preferentially used Kerberos since Win2K, which means that pretty much any in-practice Windows network you'd like to hack in to is using a real security scheme.

I mean, really. This article isn't about how much faster a GPU is than a CPU for hash cracking (after all, four days to reverse a hash is still unacceptable, and that's brute forcing it and not using one of the widely available NTLM rainbow tables), it's about how much NTLM sucks and Microsoft should have never contravened the first rule of cryptography and tried to roll their own.

Re:Who cares? (0)

Anonymous Coward | more than 2 years ago | (#36344840)

The KDC is not the weakest link. Goodbye.

Re:Who cares? (0)

Anonymous Coward | more than 2 years ago | (#36344872)

>four days to reverse a hash is still unacceptable
Your opinion, mate, not mine.

Re:Who cares? (1)

Tinctorius (1529849) | more than 2 years ago | (#36344930)

Mod parent up. This tool has no further practical applications and it is not news that brute forcing works better with GPUs than CPUs. It's exactly what they're meant to do.

1Password FTW (1)

rekoil (168689) | more than 2 years ago | (#36344806)

Shameless plug follows...

Seriously, once you're free from having to remember your own passwords, you can make them as long and complex as you like, and you can use a different *truly random* password for every login, so one compromise won't lead to others. There are freeware workalikes, but none that match 1P's feature set (syncing, browser auto-fill/change plugins, etc). Highly recommended.

Re:1Password FTW (1)

Anonymous Coward | more than 2 years ago | (#36344870)

I like LastPass better but I agree that everyone should use one of these services. The reason I like LastPass is you can use it on pretty much every platform out there for free and if you pay $12 a year you get smartphone apps and mutlifactor authentication. Also, and most importantly, LastPass is a really good company. They merely suspected they might have been attacked over their network a few weeks ago and they took thorough measures to ensure that the public was notified. Compare that to companies like Playstation and I think you will see why I suggest people use LastPass.

Re:1Password FTW (0)

FrankSchwab (675585) | more than 2 years ago | (#36344966)

1Password looks like an excellent browser-based password solution, but as a system solution, it leaves something to be desired. It doesn't appear to support a Windows Login, or non-Browser based apps (like the VPN software I'm asked to use). More comprehensive solutions are available from Digital Persona, LastPass, RoboForm, Authentec, etc.

Even more shameless plug than yours follows:
Buy an HP Business class laptop with a Validity fingerprint sensor. Having participated in the development of the fingerprint sensor, the hardware and software security architectures, I can say that this type of attack simply won't keep you up at night. Choose an arbitrarily long and complex password, and let the fingerprint sensor remember it for you. Choose different long complex passwords for all your apps and websites, and let the fingerprint sensor remember it for you. A quick swipe at the login prompt, and your password is decrypted and presented as securely as it's possible to do on a PC. 5 characters, 6 characters, 9 characters? Forget it; choose 50.

Windows problem! (3, Informative)

SmilingBoy (686281) | more than 2 years ago | (#36344810)

This is really a Windows problem. Windows uses a simple, fast hashing function (I think some version of HMAC). This means that an attacker can churn through many passwords very quickly (apparently billions per second per the article). You should really use a slow hashing function that takes around 0.1 to 1 seconds to calculate one hash on the server. Even a GPU will then take very long! Plus don't forget salt (different per user) against rainbow table attacks, plus key strengthening. Something like bcrypt is pretty good, but scrypt is probably even better as it does not only require a lot of CPU time but also significant memory (making dedicated hardware crackers much more expensive).

Re:Windows problem! (1)

thoughtsatthemoment (1687848) | more than 2 years ago | (#36344964)

even if the hashing function is fast, you can use many iterations to slow it down.

Re:Windows problem! (1)

dave420 (699308) | more than 2 years ago | (#36345038)

Exactly. That was the problem with the password storage on Blackberries. It iterated the HMAC once, whereas iOS 4 does it 10,000 times. Clearly an implementation fault.

Mitigation (0)

Anonymous Coward | more than 2 years ago | (#36344816)

For now, you should a) use more characters (say, 12) and b) include symbols in the alphabet. Assuming 25 symbols, you'd then 1.88*10^23 possible passwords already (that's not counting shorter ones!), which would still take your GPU about 1.8 million years to go through.

So for now, we're safe - although computers will get faster, and it's interesting to see what'll happen in the future. Will we ever be forced to remember complicated 30-character passwords because everything else is unsafe? Will we want to - will we come up with something better than passwords so we don't have to?

Moore's Law (1)

Grindalf (1089511) | more than 2 years ago | (#36344820)

Give it a 4 years and your digital watch will do the lot in 3 femto seconds, computing power has always been increasing over time. Don't blame GPU's for being well made! Most of this stuff can be stolen at typing point by microwave hacking anyway ...

Faulty Assumtions (3, Insightful)

imsabbel (611519) | more than 2 years ago | (#36344824)

A 6-7 letter password only using letters and numbers is NOT strong.

It would be trivial to cover it with rainbow tables and have near realtime cracking even without GPUs.

_Not weak_ would be 10 letter+, with a salt. Would make brute forcing not really that easy anymore...

If only... (1)

oGMo (379) | more than 2 years ago | (#36344838)

If only storage technology had kept up with GPUs! Instead of being limited to 8 character passwords because of stringent storage limitations, we could use entire passphrases that might be both fairly easy to remember and far more challenging for password guessing. But I guess we'll have to wait for some sort of technological breakthrough...

:p

Re:If only... (0)

Anonymous Coward | more than 2 years ago | (#36344888)

Actually we do need to wait for a breakstrough ... unfortunately. At the company I am with right now, we still have some very old legacy systems, which require us to have a max of 8 characters for the password. Longer passwords are not supported. Also, sadly, many applications still use unsalted passwords by default. Yes, even newer ones ... on a similar note, for some systems I still have to keep an SSH 1 RSA key around to log into some systems ...

Less than Ten Characters? (0)

Anonymous Coward | more than 2 years ago | (#36344844)

Does anyone really use less than ten character passwords anymore?

Ten is the minimum as far as I'm concerned. It IS NOT that difficult to remember a string of ten characters. Hell, even twenty isn't that bad. Yes. TWENTY!

Re:Less than Ten Characters? (1)

ColdWetDog (752185) | more than 2 years ago | (#36345004)

Does anyone really use less than ten character passwords anymore?

Your bank. My bank. The nuclear reactor down the street. All sorts of folks.

Cry me a river (1)

Anonymous Coward | more than 2 years ago | (#36344846)

Yeah, brute forcing NTLM login passwords. What's next, brute forcing your bank's 4 digit pin code? Please, give us a break. From wikipedia on NTLM: http://en.wikipedia.org/wiki/NTLM

Microsoft no longer recommends using NTLM in applications:

Implementers should be aware that NTLM does not support any recent cryptographic methods, such as AES or SHA-256. It uses cyclic redundancy check (CRC) or message digest algorithms (RFC1321) for integrity, and it uses RC4 for encryption. Deriving a key from a password is as specified in RFC1320 and FIPS46-2. Therefore, applications are generally advised not to use NTLM.

Aren't mosts passwords 8 or more characters? (0)

Anonymous Coward | more than 2 years ago | (#36344858)

So, if 6 chars takes 4 seconds and 7 chars takes 1050 seconds then it seems to suggests it's scaling at 256x per character. So are we talking ~260,000 seconds (3 days) for 8 characters?

Re:Aren't mosts passwords 8 or more characters? (1)

pauldmartin (2005952) | more than 2 years ago | (#36344892)

It's exponential based on the number of bits, not linear, so for longer passwords even longer.

You criticized us, but ... (0)

Anonymous Coward | more than 2 years ago | (#36344876)

See? Hashing passwords is overrated!

Yours sincerely,

Sony

Use a different hash (0)

Anonymous Coward | more than 2 years ago | (#36344908)

So, make password hash computation more expensive:

http://www.tarsnap.com/scrypt.html

Slow hashing algorithm (1)

matzahboy (1656011) | more than 2 years ago | (#36344918)

Just make the hashing algorithm slower. For example, let's say you use md5 to hash the passwords. Hash the password 1000 times with md5 instead of just once. This will increase the time it takes to crack the passwords by a factor of around 1000.

Re:Slow hashing algorithm (1)

leuk_he (194174) | more than 2 years ago | (#36345064)

No it won't. Running the same hash multiple times does not make it better. that is not how crypto works. Besides that, that would make it incompatible with older NTLM systems...

The password needs to be strong enough. Acrtually in NT passwords can be 255 chars long. maybe there is even room for improvement [dilbert.com]

SmartCards (1)

DaMattster (977781) | more than 2 years ago | (#36344920)

Since GPUs are rendering traditional passwords insecure and obsolete, why not go with a broader usage of smart cards? Also, build in mechanisms to deny IP addresses from machines that are attempting to use brute force. I do it with OpenBSD's PF. After so many failed attempts over a period of time, the IP gets blacklisted. After 24 hours, the blacklist gets purged.

Big-O complexity, look it up (1)

deapbluesea (1842210) | more than 2 years ago | (#36344946)

So the TFA proves that password cracking is exponential in the length of the password, and that GPUs cut down on the rather large constant in front of the exponent. This still does not eliminate the fact that each digit added increases the cracking time exponentially. In other words, use a longer password. Of course, NTLM is a farce since it only hashes 8 byte chunks, so you can't up the cracking time by more than X^8. The moral of the story here is that GPUs are faster than CPUs (for some specialized applications), yet you can still overwhelm them using a longer password. The other moral is that NTLM is an utter failure, but we all knew that.

If anyone really cared enough, they could build a single-purpose circuit to calculate hashes and compare with the hash file. With enough money invested, you could easily beat any GPU by a couple orders of magnitude. That still doesn't make this news worth discussing as the other side can up the ante by adding to the password length again (among many other things already mentioned such as salts).

Re:Big-O complexity, look it up (1)

jimicus (737525) | more than 2 years ago | (#36345052)

Is NTLM still in use? It's been deprecated for years - is it even enabled by default on recent versions of Windows?

Re:Big-O complexity, look it up (1)

Hatta (162192) | more than 2 years ago | (#36345132)

This still does not eliminate the fact that each digit added increases the cracking time exponentially. In other words, use a longer password.

There's only so much entropy a human brain can memorize easily. If you try to make it easier to remember, by making it pronounceable, or even using words, that decreases entropy defeating the purpose of extending your password.

Dunno what solution there is when computers can brute force passwords longer than a human can memorize.

long random passwords (1)

Doctor Device (890418) | more than 2 years ago | (#36345002)

it seems to me, if your password is random, mixed-case alphanumeric, and fairly long, there is an added layer of security against a brute-force hash attack like this. that being that the incorrect hashes will just be jumbled strings of letters and numbers... but the correct password will be, as well. how would such an attack differentiate the valid password from the invalid in this situation?

Old News. (0)

Anonymous Coward | more than 2 years ago | (#36345010)

So if anything, this reaffirms my belief that biometric authentication is the way future security measures should go. Of course dual layer: biometric authentication as well as a password, but biometric authentication none the less. But I've known about this for years... not really anything new. And a 15 character password with upper and lower case letters, numbers, and symbols will still take forever on either.

Strong passwords? Not really... (0)

Anonymous Coward | more than 2 years ago | (#36345032)

Cheap GPUs Rendering Strong Passwords Useless [...] a password of 'fjR8n' can be broken [...]

"fjR8n" is not a "strong password" by any definition, unless you think password crackers are limited to dictionary attacks. 5-character rainbow tables are fairly easy to obtain, and even a brute-force attack is trivial on something that short.

All my passwords are 8 characters or longer; important ones (login, e-mail) are 16 characters or longer. Really important ones (used to encrypt sensitive business data) are over 24 characters long. That doesn't even include the salting that most systems add (although a tailor-made cracker can make that irrelevant).

Challenge respose is dead, almost. (1)

louarnkoz (805588) | more than 2 years ago | (#36345054)

The problem with NTLM has been known for some time, but it is not just NTLM. It is in fact any challenge response protocol. Check this slide deck presented at the IETF in 2005: http://www.huitema.net/talks/ietf63-security.ppt [huitema.net] . The punch line is simple: don't rely on challenge response protocols! If the attacker can see both the challenge and the hash, and if the password can be remembered by the user, it will probably be cracked.

NTLM? Please be serious... (4, Insightful)

pedantic bore (740196) | more than 2 years ago | (#36345074)

The title of the article is extremely misleading.

I don't really care that someone can break short passwords generated via MD4. MD4 is very broken. NTLM is essentially 1992-era technology that was later picked up by Microsoft, who now deprecates its use.

When a GPU can break 15-character AES256 keys, then I'll start to worry about the security of my 24-character key.

NTLM? Seriously? (1)

cortana (588495) | more than 2 years ago | (#36345090)

What kind of incompetent fool would still use such a pathetically weak password hashing scheme?

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

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>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...