Whitepixel v2 now brute forcing 33.1 billion password/sec | Hacker News Reader

Whitepixel v2 now brute forcing 33.1 billion password/sec

blog.zorinaq.com

37 pointsmrb36 comments

I suppose that means if someone managed to get their hands on a database with MD5 hashed password and we disregard the time it takes to query the harddrive for a match; it could (stupidly) brute-force it's way to any 5 character password consisting of a-Z, 0-9 and !"#€%&/()=?+ in about 0.06 seconds. Or a 6 character password just under a minute.

That's pretty impressive.

Then again, anyone who works on md5 password "cracking" for a living would likely already have the set of all 5 character printed passwords hashed and sitting in a database ready for recall with no need to speedily crank through them.

To understand why your comment does not make sense, please read this:

http://en.wikipedia.org/wiki/Salt_%28cryptography%29

There have been an embarrassing number of cases where an application has used the same default salt on all passwords.

That assumes the Gawkers of the world salt their passwords...

Overkill, considering a lot of people still use 'password'.

btw, the url you list in your profile appears to be blocked by openDNS, reckons it's a phishing site.

It's an email redirection service I've been using since 1994.

This is very impressive.

Think of all the BitCoins they could create with a setup like that (I get an average of 50 coins every 26 minutes with http://www.alloscomp.com/bitcoin/calculator.php).

At a current market value of about USD$0.22 per coin, this equates to about USD$25/hour.

Of course, BitCoin uses SHA256, but how much different from MD5 can that be?

BitCoins dynamically adjusts the computation needed in order to claim coins. It will just make the computation harder. Of course, you would get more than the other users with less CPU power.

You'll really clean up until the difficulty increases though.

> How much different from MD5 can that be? Answer: Very.

(MD5: 128 bit | SHA256: 256 bit) :: (2^256/2^128 = 2^128) => 3.40282367*10^38 of a larger keyspace.

I know nothing about the specifical implementation details of either hashing method (and I eagerly await tptacek to offer a far more comprehensive response) but I'm sure the difference in keyspace alone is enough to make this practically impossible.

Interesting. Would you mind sharing some information regarding your hardware and performance (ghash/s)? Does your estimate include amortization of hardware cost, electricity consumption? Because the general consensus is that BTC generation is not cost-effective unless:

a) One does not pay for resources consumed. b) Speculates about future value of BTC.

Regardless, very impressive. I would love to hear more!

Hm, there is a market value for bitcoins? 25$/hour sounds like a very good deal - as long as power consumption is less, it is a license to print money?

Maybe this is the final incentive for me to look into EC2...

EC2 is NOT cost-effective at all for hash computations as I describe in detail in:

http://blog.zorinaq.com/?e=42

(This is the machine I built to develop whitepixel).

I'm not a bitcoins expert - but wouldn't any jump in the availability of bitcoins necessarily cause deflation, as with any currency?

If someone finds a way to generate,say, 5x more bitcoins that what the average expected amount is - they have a temporary advantage, but once those coins hit the market, the market is diluted and will quickly catch up.

Bitcoins has replaced mining gold with generating bitcoins - so it will be harnessing server infrastructure and good code / math -vs- digging big holes in the ground.

That's true. Also, as more computing power is added to its network, the difficulty of the hashing problem is increased to maintain the bitcoin creation rate at about 50 per ten minutes.

They say there is a limited amount of BitCoins, though - I think 21 million?

the difficulty of the calculations is adjusted so that 50 bitcoins will be released every 10 minutes. so this would only affect the distribution of bitcoins, not generation speed.

Let's stop calling it brute-forcing - it's really not - or at least not calling it decrypting.

Here are the usage instructions...sure sounds like brute force to me. Perhaps you could explain why it isn't?

    Usage: ./whitepixel [OPTION]... [<hash>]

    Main arguments:

      -c <charset>    Generate candidate passwords using the specified charset
     which can be:
                        lower  Lowercase
                        upper  Uppercase
                        digit  Digits
                        print  Printable ASCII characters and space [0x20-0x7e]
                        all    All bytes [0x00-0xff]
                      (default: lower)
      -l <length>     Attack passwords of this length (default 5)
      <hash>          MD5 hash to attack (default 00...00)

What is the minimum safest length when using MD5? I remember seeing 14 somewhere but I cant find the citation. Not forcing everyone to use 14 chars of course but adding salt.

Don't use MD5.

This only gets faster, not slower. No matter how much you salt your passwords, soon they will be able to crack your passwords fast enough. And soon there will be rainbow tables of salts.

What would you recommend doing then? (New to this stuff)

I suspect tptacek will come in with some sound advise. But bcrypt seems to be the way forward.

cf. http://codahale.com/how-to-safely-store-a-password/

bcrypt or scrypt (http://www.tarsnap.com/scrypt.html). bcrypt lets you more or less arbitrarily set the computational complexity (in terms of instructions) of key generation. scrypt is newer (2009), but has the attractive property that it lets you arbitrarily set the memory complexity instead (how much memory it takes). This is attractive because key generation with a large memory requirement is more expensive to massively parallelize with an ASIC/FPGA farm.

If you have a seriously good reason for not using either of these, which you probably don't, "stretched" (iterated thousands of times) and salted SHA-2 or MD5, or PBKDF2 ( http://en.wikipedia.org/wiki/PBKDF2 ) can be acceptable alternatives.

Thanks a bunch rmc, and sparky! I'll definitely be spending some time reading up on these tonight.

That's just not true. If your salt is 1000 characters long, they will need more energy than the whole universe has to bruteforce it.

the point of adding a salt to the passwords is not to make decrypting the individual passwords harder - the salts are kept in plaintext - but to make it impossible to prevent the use of rainbow tables. that is, having longer salts will only make it harder for finding out all the people with the same password.

That's assuming hacker knows the salt, which is not always the case.

My prediction: After there are loads of MD5 rainbow tables with all the passwords a human could use, people will make rainbow tables with salts. First one byte of salt, then two. Granted this gets exponentially harder, but eventually it'll be close.

Except anybody playing this game has the salt, there's no need to guess it.

Passwords and MD5?

Microsoft is worse: passwords and MD4.

(Windows' newest password hashing algorithm, NTLM, is just a plain MD4 hash of the password. I estimate my 4x5970 machine can crack NTLM hashes at a rate of about 45 billion per second.)

Calling it Microsoft's newest algorithm is very misleading. Microsoft have themselves deprecated NTLM and recommend Kerberos.

Technically, NTLM will always be the "newest" unless they invent something newer, but it doesn't mean you need to use it.

And Microsoft's Kerberos implementation (AD) hashes passwords on the domain controller using... NTLM!

How am I misleading?

Reply on news.ycombinator.com