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

61–70 of 90 posts

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

#61

Post by whyenot »

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.

If I had to come up with a new long password every three months I'd do what undoubtedly countless other people would do in the same situation: I'd write down my password somewhere nearby the computer so I could look it up when I needed it.

Overly onerous password requirements reach a point where they no longer increase security, they just shift vulnerability to a new area. They also piss off users.

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

#62

Post by drusenko »

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…

> Bcrypt and scrypt look great, but not fundamentally any better than longer passwords.

A technical-only solution is infinitely better than one where you try to change user behavior. You think memorizing a long password is easy because it's easy for you. Try telling that to someone who's 72 and just started using the Internet.

The reality is that anything that reduces friction to adoption is almost always a positive choice for any given company. There are exceptions, like banking, but for the most part, this is true.

This all ignores the fact that longer-length passwords are almost completely pointless, anyway, for a ton of reasons:

(1) The data you store on behalf of the user is probably not important enough to warrant the (very strong) inconvenience.

(2) Proper password storage ((b|s)crypt) can already mitigate a lot of these risks. If tuned properly, even a 4-character bcrypt password can become more computationally difficult to "reverse".

(3) Short passwords can be bruteforced over the wire? Well, you can prevent people from doing this. You control the environment and can make brute-forcing attacks against your login mechanisms unfeasible.

(4) For this to matter at all, some attacker has to steal the entire authentication table with all of the hashes. If that happens, the number of ways you're fucked is much larger than just your users having to change their passwords where re-used elsewhere.

Fundamentally, for most use cases, it should be a user's choice to opt to use a longer password that would be more difficult to crack, or use a shorter password for convenience.

Google already does this by showing a password strength bar when choosing a password. Unless you store very sensitive data, who are you to make that decision on their behalf?

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

#63

Post by drusenko »

whyenot wrote: post #61
yafujifide wrote: post #44

Earlier quoted context omitted.

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

If I had to come up with a new long password every three months I'd do what undoubtedly countless other people would do in the same situation: I'd write down my password somewhere nearby the computer so I could look it up when I needed it. Overly onerous password requirements reach a point where they no longer increase security, they just shift vulnerability to a new area. They also piss off users.

If I had to change my password every three months, I'd do something even simpler: I'd stop using the service.

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

#64

Post by pjscott »

meric wrote: post #55
tptacek wrote: post #51

Earlier quoted context omitted.

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.

The good news is, there are libraries for bcrypt for most every major language out there, and they are extremely simple to use. Some languages also have scrypt libraries, which is even better. Either will be a huge improvement over plain salted SHA-1.

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

#65

Post by 16s »

The sha1 hashes he provides are super weak. I can crack half of them in less than 30 seconds on my CPU with my software (16crack). Hardly material for a GPU:

EF8420D70DD7676E04BEA55F405FA39B022A90C8 "Password!"

5BAA61E4C9B93F3F0682250B6CF8331B7EE68FD8 "password"

A9993E364706816ABA3E25717850C26C9CD0D89D "abc"

1902E3D6FC4E78A0BCC50BA12B882769AFBF4A8C "bad"

8F2005004F8BAA7A1090A9BF3B03C48D38E78157 "P4s$"

CD3724AC40034097A3D27865D710E4F791B6AEDB "Bwah"

7110EDA4D09E062AA5E4A390B0A572AC0D2C0220 "1234"

http://stacksmashing.net/blogfiles/2010_11_15/sha1_hashes.tx...

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

#68

Post by msmith »

16s wrote: post #65

The sha1 hashes he provides are super weak. I can crack half of them in less than 30 seconds on my CPU with my software (16crack). Hardly material for a GPU: EF8420D70DD7676E04BEA55F405FA39B022A90C8 "Password!" 5BAA61E4C9B93F3F0682250B6CF8331B7EE68FD8 "password" A9993E364706816ABA3E25717850C26C9CD0D89D "abc" 1902E3D6FC4E78A0BCC50BA12B882769AFBF4A8C "bad" 8F2005004F8BAA7A1090A9BF3B03C48D38E78157 "P4s$" CD3724AC4003409…

How long does it take your software to crack the other half?

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

#69

Post by 16s »

msmith wrote: post #68
16s wrote: post #65

The sha1 hashes he provides are super weak. I can crack half of them in less than 30 seconds on my CPU with my software (16crack). Hardly material for a GPU: EF8420D70DD7676E04BEA55F405FA39B022A90C8 "Password!" 5BAA61E4C9B93F3F0682250B6CF8331B7EE68FD8 "password" A9993E364706816ABA3E25717850C26C9CD0D89D "abc" 1902E3D6FC4E78A0BCC50BA12B882769AFBF4A8C "bad" 8F2005004F8BAA7A1090A9BF3B03C48D38E78157 "P4s$" CD3724AC4003409…

How long does it take your software to crack the other half?

That depends on the number and type of CPUs available. I know better than to race my CPU against a GPU. I won't win. I'm just pointing out the fact that if you have a fast GPU (or a cluster of them as the article suggests), then the hashes should be much better than what is provided. With those hashes, any CPU based cracker can do them easily.

The article says 1 to 6 character passwords. With 12 cores, I can enumerate the full printable ASCII character set in about 30 hours, but I would not try to do that. I would use patterns and word lists first. After 6 to 7 characters, brains begin beating the hell out of brute speed.

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

#70

Post by qjz »

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…

Regardless of the length, passwords are obsolete, at least when used in single factor systems. The biggest problem with authentication is identity assurance, an attribute that passwords simply don't possess. Better and more factors are necessary to provide true security in the future, and we're simply making due with passwords in the meanwhile. Phishing and Firesheep are ready examples of the weakness of passwords, and they're not even the easiest methods of compromise available. Passwords have a use, but so do other forms of security-by-obscurity, a category that passwords will inevitably fall into.
Post reply on HN