A call for password algorithm disclosure

Not even 24 hours after my Defcon talk, in which I expressed my opinion that password hashing policies should be disclosed, Twitter finds out that @UKTesco believes this is acceptable: Passwords are stored in a secure way. They’re only copied into plain text when pasted automatically into a password reminder mail.

No.  If you can recover the plaintext of the password to send in an unencrypted email, your passwords are not "stored in a secure way."  They are stored in a fully insecure way.

LinkedIn: Unsalted SHA1.
Yahoo Music: Plaintext.
eHarmony: Unsalted MD5.
RockYou: Plaintext.

This is unacceptable.  This is 2012, not 1982.

My proposal is very simple:

Disclose your password hashing algorithm publicly on your website.


If you are using BCrypt, tell us.  If you are using PBKDF2 with a high iteration count, tell us.  If you are using SCrypt, tell us.  If you are using unsalted anything... fix it before you tell us.  If you are using plaintext, fix it before you tell us.

The new user behavior should be:
If a website does not tell you what hashing algorithm they use, assume they use plaintext.


This is the only reasonable way to deal with the fact that websites, in large numbers, do not take their password security seriously.

For website operators who are concerned about this: Why are you concerned?  If you are using a good password hashing algorithm, this is a very good thing to advertise.  If you do NOT use a good password hashing algorithm... people will find out eventually.  One way or another, people will find out, and it's not a good thing when they find out you've been treating their sensitive passwords as common temp data.

Please feel free to share.  Let's fix this problem.

Defcon 2012!

I'll be there this afternoon!

Just a reminder - my talk is at noon, Saturday, in P&T - if you want to meet in person & ask me questions, this would be a great time!

Otherwise, feel free to ping me at @Bitweasil if you want to find me.  Enjoy Defcon, and stay safe out there!

Installing Cryptohaze on Amazon EC2 GPU instances

There have been a number of scattered requests to support my tools on EC2 GPU nodes in a more "supported" manner than the current set of hacks.

I've written a script that will take an Amazon GPU node, install the needed libraries, install my tools, and optionally point the Multiforcer at a server of your choosing.  This works well with spot instances at $0.35/hr instead of $2.10/hr.  The script is reasonably tested, and works fine for me!

Instructions and script

Forum discussion thread for feedback

Enjoy!

Cryptohaze Rainbow Tables now available for purchase!

I've finally set things up to allow easy online purchase of the generated GPU rainbow tables.

NTLM length 8 tables and MD5 length tables are both available now at https://cryptohaze.com/purchase_tables.php - enjoy!

Password salting: Why it matters

I'd like to take this afternoon to explain why salts matter so very much in password storage.  Why am I qualified to write this?  Because I write password cracking tools, and have focused on attacking large lists of unsalted hashes very efficiently.  And salts make my life very difficult.

Consider this a very long response to @jimblandy's tweet this morning.

I'm not picking on him specifically - this is a sentiment I see repeated over and over, in a wide variety of places.  And it's time to respond.  Also, it appears to be #passwordssunday for some reason.

Hardware pictures from the crack-a-thon

Some hardware shots from yesterday of the more fun stuff...

154 Billion NTLM/sec on 10 hashes

It's a good day when you see the following on 10 hashes:

Yes, that's 154B - as in Billion.  It was done entirely with AMD hardware, and involved 9x6990, 4x6970, 4x5870, 2x5970, and 1x7970 - for a total of 31 GPU cores in 6 physical systems.  We had another 11 cards with 15 GPU cores left over - we didn't have systems to put them in (mostly nVidia).

For more details, read on...

Torrents updated - please refresh your torrent files!

If you've downloaded the rainbow table torrents from http://cryptohaze.com/gpurainbowtables.php, please redownload them.  You can put them in the same place and the torrent will resume.  I gave up on UDP trackers as my only trackers, and am now running a Cryptohaze-specific torrent tracker that should provide much better results and reliability, as well as better behavior for clients behind firewalls.  Thanks!

On EC2 instances and password cracking

The general wisdom, rightly so, is that EC2 GPU instances are awful ways to spend your dollars for password cracking.  They're running obsolete Teslas, which are underclocked nVidias, which we all know are terrible for password cracking.

But... still.  I decided to go benchmark, because I don't like saying something sucks without good cause.

Let's say we're interested in a few NTLM length 8 passwords.  Fairly standard for a corporate audit.

I know, I know - glacially slow compared to "modern hash cracking rigs" - but how much does it cost to do?

Well, at 3B hashes per second, length 8 (95 characters) will take 615 hours.  At $2.10/hr standard GPU instance pricing, that's nearly $1300!  Ouch!  You're really better off buying a 6990 or something at that price!

But what about spot pricing?  Amazon clearly isn't having them heavily utilized, because their spot price is $0.346/hr right now.  And that, my friends, works out to $213.  Which is a whole lot more interesting - especially since that's the total cracking cost, if you use one instance and a month, or a bunch of instances and a lot less time.

Just something to think about...

Updated July 31 2012
If you are looking to actually do this, http://blog.cryptohaze.com/2012/07/installing-cryptohaze-on-amazon-ec2-gpu.html has links to the scripts to do so.  And the speeds are even better, making the cost less!

Using oclHashcat-0.09 on Ubuntu 10.04

If you're a beta tester for oclHashcat-plus 0.09, you may have noticed that it doesn't work on older versions of Ubuntu.  You'll probably get a glibc version error - something along the lines of:

./oclHashcat-plus64.bin: /lib/libc.so.6: version `GLIBC_2.14' not found (required by ./oclHashcat-plus64.bin)

The bad news is that Ubuntu 10.04 uses an older version of GLIBC.  The good news is that this shouldn't stop you from being able to use 0.09 on 10.04!  The trick is Linux chroot support - you create a 12.04 in a chroot, bind the right stuff in, and run oclHashcat.