Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

New 25 GPU Monster Devours Passwords In Seconds

securityledger.com

Post reply on HN
Print view View original

41–50 of 91 posts

Re: New 25 GPU Monster Devours Passwords In Seconds

#41

Post by nwh »

dbaupp wrote: post #33
nwh wrote: post #16

Earlier quoted context omitted.

I have attempted this, and I believe others on the wider Internet have as well. Essentially it ended up being slower than if the central servers CPU was used to attack the hashes instead. With only JavaScript available to do the hashing, the maximum per client was disappointingly slow, around 2000 hash/second each if I remember correctly. It might be better now with faster JavaScript engines, but I wouldn't bet on it…

How long ago did you try this?

About a year and a half ago. Long enough that I can't find the source to try it out in a newer browser.

Re: New 25 GPU Monster Devours Passwords In Seconds

#42

Post by ck2 »

Also makes me think we should be using AES256 at a minimum with SSL and not AES128 anymore.

With AESNI acceleration available on most servers, there is little penalty to upgrade.

They say AES128 is safe until about 2030 but who knows if that took into account super-GPU clusters.

(insert imagine a Beowulf cluster of these... comment here)

Re: New 25 GPU Monster Devours Passwords In Seconds

#43

Post by sspiff »

_ikke_ wrote: post #36
sspiff wrote: post #31

Earlier quoted context omitted.

Since reading that xkcd, I use phrases as passwords, using a simple Ruby script to generate them: w = File.readlines('/usr/share/dict/words').map { |w| w.chomp }.reject { |w| w !~ /^[A-Za-z]+$/ }; 3.times { print w[rand * w.size] }; puts I generally get an easy to remember password after about 3 tries. The biggest issue I have with this is typing in passwords on mobile devices.

Aren't phrases easier to type on mobile devices than letter / number combinations? I always find it annoying to have to switch to different keyboard modes (text / numbers), or having to hold the letter / number key for a few seconds.

Sure, the simple characters make it a bit easier, but the phrases tend to be much longer.

The error rate on a touchscreen keyboard is high enough to really become a problem at 20+ characters when you only see the last typed character (no password review).

Re: New 25 GPU Monster Devours Passwords In Seconds

#44

Post by pkorzeniewski »

Recently I was thinking about alternative ways of implementing authorization security and I had, maybe a silly, idea - wouldn't it be more secure to always log user in and when given a wrong password, "simulate" (generate) account data? In my opinion it would be much harder to write an algorithm detecting if account data is real or not, and isn't the point of cracking to get access to user data?

Re: New 25 GPU Monster Devours Passwords In Seconds

#45

Post by ZoFreX »

_b8r0 wrote: post #22

The problem with all of this is that security specialists (of which I am one, guilty as charged) have historically campaigned for more complex passwords. This worked well for conventional (non-clustered, non-accelerated) password cracking mechanisms. Sadly, this starts to fall apart with accelerated and/or distributed cracking. On average I crack a few hundred passwords a week, and more often than not organisations h…

It's worth pointing out that length is not important, only entropy is important. If you create a really long phrase by forming a sentence from very common English words, the entropy is actually really low, and if everyone started doing this you can bet your boots the password crackers would catch up.

However you create your password you should take a stab at calculating the entropy (and incidentally a 10 character truly random password with alphanumeric+specials will be very hard to crack - it's the fact that the passwords are mutations of a seed word that makes them weak, and not their short length)

Re: New 25 GPU Monster Devours Passwords In Seconds

#46

Post by shocks »

I wonder how much heat this this generates? How does it stay cool? I have two GTX 670s in SLI and they can get to about 60 degrees with a gap between them... This many cards sandwiched so close must get really really hot. I don't see any water cooling...

Re: New 25 GPU Monster Devours Passwords In Seconds

#47

Post by rmc »

michaelt wrote: post #35
peteretep wrote: post #8

The numbers are ... misleading ... and choosing NTLM hashes seems like bordering on misinformation. Taking SHA-1 (which YOU MUST NOT USE for password hashing blah), it manages 63 billion a second. To try all the passwords for that in the alphanumeric space: - 10 chars: 35 weeks - 11 chars: 44 years - 12 chars: 2,800 years - 16 chars: 11 times the age of the sun 10 chars for bcrypt: 600,000 years... http://www.wolfram…

LinkedIn used unsalted SHA-1, had their passwords leaked, and within a month 90-95% of leaked passwords were cracked[1]. Admittedly LinkedIn isn't a critical application calling for people's most secure passwords - but it's evident that only 5-10% of users use passwords that take more than 1 month to crack when hashed with SHA-1. [1] http://securitynirvana.blogspot.co.uk/2012/06/final-word-on-...

Admittedly LinkedIn isn't a critical application calling for people's most secure passwords

People re-use passwords. Often it's not access to the LinkedIn account that's the problem, but that that same password will give you access to their email account, after that, you have everything.

Re: New 25 GPU Monster Devours Passwords In Seconds

#48

Post by rmc »

ZoFreX wrote: post #45
_b8r0 wrote: post #22

The problem with all of this is that security specialists (of which I am one, guilty as charged) have historically campaigned for more complex passwords. This worked well for conventional (non-clustered, non-accelerated) password cracking mechanisms. Sadly, this starts to fall apart with accelerated and/or distributed cracking. On average I crack a few hundred passwords a week, and more often than not organisations h…

It's worth pointing out that length is not important, only entropy is important. If you create a really long phrase by forming a sentence from very common English words, the entropy is actually really low, and if everyone started doing this you can bet your boots the password crackers would catch up. However you create your password you should take a stab at calculating the entropy (and incidentally a 10 character tr…

It's worth pointing out that length is not important, only entropy is important

Exactly. This is a weak password: "aaaaaaaaaaaaaaaaaaaaaaaaaaaaa" or "qwertyuiopqwertyuiop"

Re: New 25 GPU Monster Devours Passwords In Seconds

#49

Post by DanBC »

raverbashing wrote: post #23
alexkus wrote: post #18

Earlier quoted context omitted.

True, but in reality you're probably sending that password over something less secure (like an SSL connection) that doesn't require quite as long (but still a very long time) to crack. Anything is only as secure as the weakest link in the chain. If (I'm sure you don't) you allow your browser to save that password so that you don't have to enter it every time then you just need one cleverly designed trojan to be run o…

There you go 30 chars password don't matter. Sure, it's not low hanging fruit, but it's not troublesome if you're the target Why? Weakness 1: Because it's written down somewhere. Weakness 2..n: weaker links in the chain

> Weakness 1: Because it's written down somewhere.

This should be part of your risk assessment. For most people and most passwords the risk is not someone riffling through your wallet to find the card with your 30 character password. The risk is from criminal gangs hacking a system and downloading a huge database of usernames / password hashes, and then performing an offline attack on those hashes.

For most people writing a good password down and keeping the password safely is better than using a weak password.

Re: New 25 GPU Monster Devours Passwords In Seconds

#50

Post by chubs »

peteretep wrote: post #8

The numbers are ... misleading ... and choosing NTLM hashes seems like bordering on misinformation. Taking SHA-1 (which YOU MUST NOT USE for password hashing blah), it manages 63 billion a second. To try all the passwords for that in the alphanumeric space: - 10 chars: 35 weeks - 11 chars: 44 years - 12 chars: 2,800 years - 16 chars: 11 times the age of the sun 10 chars for bcrypt: 600,000 years... http://www.wolfram…

Glad to hear bcrypt is still safe; that's what i use for my apps.
Post reply on HN