New 25 GPU Monster Devours Passwords In Seconds • Hacker News Board

Re: New 25 GPU Monster Devours Passwords In Seconds

#61

Post by raverbashing » Wed, Dec 05, 2012, 1:31 PM UTC

bigiain wrote: post #53

raverbashing wrote: post #51

Earlier quoted context omitted.

True That´s why I use a 'throwaway' password for most unimportant accounts. Sure, may be easy to break, but it isn't logging in to my gmail. Don't forget also the risk of getting locked out of your account.

I fell victim to that once, when I hadn't "upgraded" the re-used throwaway password I'd used to register to see what some random website was. When my throwaway password got exposed (in cleartext facepalm! ) by PerlMonks, within a day or so someone had used it to send Acai Berry spam through my Twitter account (which 'd completely forgotten was still using a shared/throwaway password even though it had turned from "so…

Interesting. It is certainly needed to "upgrade" passwords sometimes.

My beef with 1PW is that it's a single point of failure, not to mention inconvenience/risks. For example, what if I need to check gmail in a trusted, but borrowed device.

The main issue I think is that using only one password for security is insufficient (but not necessarily go for a 2-factor auth)

Re: New 25 GPU Monster Devours Passwords In Seconds

#62

Post by nwh » Wed, Dec 05, 2012, 1:40 PM UTC

newman314 wrote: post #60

nwh wrote: post #17

Earlier quoted context omitted.

If you are genuinely interested in testing your 1Password keychain, the Jumbo builds of JTR include support for the agilekeychain, and some branches (Magnum Jumbo for example) offer OpenCL support for even faster attacks. I tried it against mine, and was significantly disappointed in how quickly even my laptop could attack it. I promptly increased the complexity of my master password.

What was it before (key length)? And what is it now?

It used to be random alphanumeric, eight characters. JTR tore through that. It's now ~15 random characters, not all ASCII.

Possibly worse, 1Password used to have a mistake in their key generation algorithm that means you could verify a password without the time-consuming key stretching, effectively making it thousands of times faster to crack. JTR doesn't use that method though.

Re: New 25 GPU Monster Devours Passwords In Seconds

#63

Post by rootbear » Wed, Dec 05, 2012, 2:03 PM UTC

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

Yeah, the iPhone keyboard is what finally got me to stop using r2d2 or c3p0 as a part of my password. And the fact that they are probably in the cracking dictionaries.

Re: New 25 GPU Monster Devours Passwords In Seconds

#64

Post by agl » Wed, Dec 05, 2012, 2:11 PM UTC

rorrr wrote: post #28

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…

> The National Institute of Standards and Technology (NIST) has issued a statement that says SSL certificates with a key length of 1,024 bits or fewer will be insufficient for security after December 31, 2010 > It is recommended that the algorithms and key sizes in the "Through 2030" row (e.g., 2048-bit RSA) should be used to provide the cryptographic protection http://csrc.nist.gov/publications/nistpubs/800-57/sp800…

RSA keys are composite numbers. Bruteforcing them involves factoring, not trying 2^n possibilities. A bruteforce of a 1024-bit RSA key possible to be published this decade and likely by 2030.

http://en.wikipedia.org/wiki/General_number_field_sieve

Re: New 25 GPU Monster Devours Passwords In Seconds

#65

Post by vonuebelgarten » Wed, Dec 05, 2012, 2:19 PM UTC

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.

Entropy is important, but multi-word passwords stills being efficient since their alphabet is quite large when compared with common alpha-symbolic-numeric passwords.

For example, a completely random password with 12 digits and upper/lower case letters have (26+26+10)^12 = 3.226e21 possibilities. Quite good unless you need to memorize this thing. I use such nonsense things for password stored in my password safe.

A password with four very common words (among the 1000 most common words in the user's native language, which I assume the attacker know) have 1e9 possibilities -- very bad. Relevant XKCD for explaining how bizarre is an English text with such restricted vocabulary: https://xkcd.com/1133/

A password with five words selected among the most 4000 words of the user's native language have 1.024e+18 possibilities. Put some uncommon/random/made-up word in the mix is enough to make a direct attack on the password non-viable and force the attacker to search for more elaborated methods. Plus side: is easy to memorize.

Re: New 25 GPU Monster Devours Passwords In Seconds

#66

Post by itry » Wed, Dec 05, 2012, 2:20 PM UTC

Keyframe wrote: post #58

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…

I'm kind of rusty on algorithmic information theory (I'm an artist, heh)! Is there such a thing as (formalized) upper limit of what we could do as far as computing combinations go? I know of Kolmogorov complexity (vaguely), but what are the hard limits and challenges of just prodding through (faster and faster as tech goes forward) combinations until success? I plan on developing a story around that and make a movie…

"what are the hard limits and challenges of just prodding through (faster and faster as tech goes forward) combinations until success?"

According to current theory of physics, every computation needs at least a certain amount of energy. So if you want to do many computations today, you will have to use a certain amount of energy today. Now lets say, you have a machine that turns any matter into energy without any loss. You put in m mass and you get out e=mc^2 energy. Problem is: You cannot get more matter into that machine today then is around you in a radius of 24 light hours.

So that would be a hard limit.

But quantum computers have proven to break that limit. One theory is that using a quantum computer means using computers in an unlimited number of parallel universes. So there is no limit to the number of calculations you can do. (See David Deutsch and his theories about parallel universes)

I think there are theories about the limits of what a quantum computer can calculate. But I dont know them. Would be interesting to read about it if there is something published.

Then again, what might look like a "hard limit" today will probably not do so tomorrow. Some time ago the "lower limit on energy per calculation" sounded like a hard limit. Then quantum computers came along and blasted through it.

Re: New 25 GPU Monster Devours Passwords In Seconds

#67

Post by joshmaker » Wed, Dec 05, 2012, 2:42 PM UTC

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…

However, the length of the average password is probably closer to 8 chars (http://www.codelord.net/2011/06/18/statistics-of-62k-passwor...) at which point the time to crack a password drops to 84 minutes for SHA-1 and 30 minutes for MD5. Also if users aren't required to use uppercase or special characters, they probably won't (http://research.microsoft.com/pubs/74164/www2007.pdf), at which case things look a lot worse.

Re: New 25 GPU Monster Devours Passwords In Seconds

#68

Post by Karunamon » Wed, Dec 05, 2012, 2:43 PM UTC

sspiff wrote: post #43

_ikke_ wrote: post #36

Earlier quoted context omitted.

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

Using dictionary words makes it easy for more modern predictive keyboards to keep up, though. Taking the XKCD canonical example, "correct horse battery staple", it's a reasonably secure and lengthy password and includes special characters.

It could also be keyed in via something like Swype or SlideIT in almost as fast as it could be keyed in on a computer keyboard.

Re: New 25 GPU Monster Devours Passwords In Seconds

#69

Post by Karunamon » Wed, Dec 05, 2012, 2:45 PM UTC

ars wrote: post #26

nakedrobot2 wrote: post #20

I haven't seen the discussion that I think is really necessary - when are we going to move beyond passwords, which are obviously growing more and more obsolete? What are we going to use instead of passwords in the future?

There are 3 types: What you know. What you have. What you are. And of the 3 What you know (i.e. password) is the most secure when used properly. It's impossible to steal without your knowledge, and it's impossible to misplace. What you have (eg. physical key) can be stolen from you - or even borrowed, used, and returned without you ever knowing. It can also be copied, and it can be lost - sometimes without being awar…

What you are.. trivial to copy - even from a distance..

A retinal print?

Re: New 25 GPU Monster Devours Passwords In Seconds

#70

Post by Keyframe » Wed, Dec 05, 2012, 2:53 PM UTC

itry wrote: post #66

Keyframe wrote: post #58

Earlier quoted context omitted.

I'm kind of rusty on algorithmic information theory (I'm an artist, heh)! Is there such a thing as (formalized) upper limit of what we could do as far as computing combinations go? I know of Kolmogorov complexity (vaguely), but what are the hard limits and challenges of just prodding through (faster and faster as tech goes forward) combinations until success? I plan on developing a story around that and make a movie…

"what are the hard limits and challenges of just prodding through (faster and faster as tech goes forward) combinations until success?" According to current theory of physics, every computation needs at least a certain amount of energy. So if you want to do many computations today, you will have to use a certain amount of energy today. Now lets say, you have a machine that turns any matter into energy without any los…

Thanks for info. Also, I found somewhat of an answer for limits of computations I was looking for: http://en.m.wikipedia.org/wiki/Bremermann%27s_limit rather fascinating!