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

Cracking Passwords In The Cloud: Amazon’s New EC2 GPU Instances

stacksmashing.net

Post reply on HN
Print view View original

51–60 of 90 posts

Re: Cracking Passwords In The Cloud: Amazon’s New EC2 GPU Instances

#51

Post by tptacek »

psadauskas wrote: post #21
umjames wrote: post #2

OK, I'll bite (and show my ignorance regarding security). What should we use in place of SHA1?

I've used bcrypt [ http://bcrypt-ruby.rubyforge.org/ ] in the past. Automatically handles a salt, and you can "tune" the number of iterations, so you can pick the cost. You can make it so the hash function takes 300ms on fast hardware, which limits the rate that an attacker can brute-force your database. Edit: Wrote up this comment before the one about scrypt. It also looks nice, but it looks like there's no or only…

You're just fine with bcrypt. scrypt is almost certainly better, but even iterating SHA1 repeatedly is still acceptable. What isn't acceptable is using a naked hash function (or a naked hash with a "salt").

Re: Cracking Passwords In The Cloud: Amazon’s New EC2 GPU Instances

#52

Post by tptacek »

Rantenki wrote: post #7

First of all, only the initial release day, and the EC2 GPU killer app has been discovered. Second, store passwords as a salted hmac, not just a shaXsum. It is still usually a singel command, and WAY more secure than simple shaX or mdX, as it eliminates the risk of prefix/postfix attacks. Adding the salt makes dictionaries pretty irrelevant (as long as each install has a unique salt). I mean GEEZ; even php does it no…

HMAC does nothing to prevent iterated brute force cracking, the kind of cracking that most benefits from GPU acceleration. There is virtually no security benefit to using an HMAC construction over the bare hash function itself.

Listen to 'jrockway.

Re: Cracking Passwords In The Cloud: Amazon’s New EC2 GPU Instances

#53

Post by tptacek »

SoftwareMaven wrote: post #49

Anybody know how tarsnap's scrypt lines up against HMAC-based key derivation[1]? In particular, let's say I used the HMAC of the password as the bases for the HKDF? [1] http://tools.ietf.org/html/rfc5869

HKDF isn't a password hash; it's a key derivation function, used to transform a passphrase into key material suitable for something like AES. It doesn't address the key security problem that scrypt addresses (iterative brute force cracking). It isn't an acceptable substitute.

You can use PBKDF2 as a password hash (even though it too is designed mostly to turn passphrases into keys), because PBKDF2 is iterated to slow down brute force attacks.

Re: Cracking Passwords In The Cloud: Amazon’s New EC2 GPU Instances

#54

Post by 16s »

With the right hash type (unsalted md4... yes, I'm looking at you Microsoft Windows Active Directory) and a top notch Nvidia or AMD graphics card, one can attempt roughly 600 million hashes per second at home in the living room.

Also, one of the teams used Amazon servers during the 2010 Defcon Crack Me If You Can contest. Here is their write-up: http://contest.korelogic.com/team_CrackHeads.html

Re: Cracking Passwords In The Cloud: Amazon’s New EC2 GPU Instances

#55

Post by meric »

tptacek wrote: post #51
psadauskas wrote: post #21

Earlier quoted context omitted.

I've used bcrypt [ http://bcrypt-ruby.rubyforge.org/ ] in the past. Automatically handles a salt, and you can "tune" the number of iterations, so you can pick the cost. You can make it so the hash function takes 300ms on fast hardware, which limits the rate that an attacker can brute-force your database. Edit: Wrote up this comment before the one about scrypt. It also looks nice, but it looks like there's no or only…

You're just fine with bcrypt. scrypt is almost certainly better, but even iterating SHA1 repeatedly is still acceptable. What isn't acceptable is using a naked hash function (or a naked hash with a "salt").

Really? All I've been doing is just picking 8 random characters as a "salt", sticking it to the password, and SHA-1 it, and you're saying its not secure? Uh oh.

Re: Cracking Passwords In The Cloud: Amazon’s New EC2 GPU Instances

#56

Post by yafujifide »

_b8r0 wrote: post #50
yafujifide wrote: post #45

Earlier quoted context omitted.

> I've been trying to get Pyrit working on the Centos image but have been having trouble compiling it. An 8 node cluster with Teslas is going to bring WPA-PSK cracking down to where WEP was a few years back for those who can afford it. Are there legitimate uses for password cracking or is this about getting access to other people's accounts?

At my day job we mostly do penetration testing and incident response. Sometimes we need to crack passwords so we have these huge files called rainbow tables that can be used to look up a very high percentage of possible passwords for given algorithms, but aren't infallible and take time to search. We sometimes crack passwords to do a password strength audit. Sometimes dictionaries aren't really enough (as someone mig…

Thanks for the information, that's very interesting.

Re: Cracking Passwords In The Cloud: Amazon’s New EC2 GPU Instances

#57

Post by 16s »

yafujifide wrote: post #33

Allow me to be the first one to argue that we should require that users use longer passwords. This is not much of a burden. Your password will last for a very long time, and it takes only a few minutes to memorize a long password. If computing power doubles every 2 years, then every two years we should bump up the required password length to match. If each character is randomly chosen from amongst 2^6=64 possibilitie…

Payment Card Industry (PCI DSS 1.2) only requires 7 characters and some must be alphabetic while some must be numeric. So "soccer1" is a perfectly valid, PCI compliant password that will be cracked in less than a minute (offline or online).

Section 8.5.10 Passwords must be at least 7 characters long.

Section 8.5.11 Passwords must contain numeric and alphabetic characters.

Re: Cracking Passwords In The Cloud: Amazon’s New EC2 GPU Instances

#58

Post by pjscott »

nl wrote: post #46
windll wrote: post #17

Earlier quoted context omitted.

Last time I checked, GPU processing has a better-bang-for-the-buck than FPGA processing, and the gap continues to widen.

I suspect the NSA doesn't care too much about bang-for-buck. 22nm FPGA's [1] seem like they would work pretty well. In an interesting twist, The Register claims that Achronix's decision to use Intel was driven in part by national security considerations. We've reported extensively on the idea that chips fabbed overseas in insecure facilities could contain hidden kill switches or backdoors that would let an opponent c…

Those are particularly interesting because they're asynchronous FPGAs -- they use local handshaking rather than a global clock to keep everything synchronized. That should make them easier to port to new, smaller process nodes, and they say it's responsible for their unusually high throughput.

Cool stuff, and all the more intriguing considering that Intel's getting involved.

Re: Cracking Passwords In The Cloud: Amazon’s New EC2 GPU Instances

#59

Post by pjscott »

yafujifide wrote: post #44
alextgordon wrote: post #39

Earlier quoted context omitted.

We can't even get people to dump IE6. How the hell are we going to get them to use longer passwords, and change them every year? Scrypt is better than longer passwords because it's actually possible to implement in practice.

> How the hell are we going to get them to use longer passwords, and change them every year? You merely require them to use longer passwords, and require them to change them every year. My university does this. They require a minimum of 8 characters, and they require that we change our password every 3 months or we can't log in.

How many people do things like changing their password from "soccer5" to "soccer6" every three months?

Re: Cracking Passwords In The Cloud: Amazon’s New EC2 GPU Instances

#60

Post by alextgordon »

tedunangst wrote: post #42
alextgordon wrote: post #39

Earlier quoted context omitted.

We can't even get people to dump IE6. How the hell are we going to get them to use longer passwords, and change them every year? Scrypt is better than longer passwords because it's actually possible to implement in practice.

People use IE6 because of external forces. You can add longer passwords to your application and still make it work with IE6.

Some do, some don't. I remember a digg survey a while back - a significant number responded that they had not upgraded because they felt no need to.

So just drop IE6 support - those people will soon wake up. But that has its own problems. If 10% of my users use IE6, and I drop support for it, that could have a significant effect on conversion rates and the like. Those people are going to do something else, maybe even go to a competitor.

The same applies to passwords. If, say, tumblr suddenly required 12 character passwords, then it would be quite a hit to their signup rates. This is simply not going to fly when there exists far less drastic measures (i.e. scrypt).

Post reply on HN