If you just want the slides of the talk, here you go:
https://cryptohaze.com/slides/Cryptohaze%20DC20%20Final%20Slides.pdf
If you're interested in a commentary on the slides, read on!
Wednesday, August 1, 2012
Sunday, July 29, 2012
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.
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.
Thursday, July 26, 2012
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!
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!
Sunday, July 22, 2012
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!
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!
Monday, July 16, 2012
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!
NTLM length 8 tables and MD5 length tables are both available now at https://cryptohaze.com/purchase_tables.php - enjoy!
Sunday, July 15, 2012
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.
Subscribe to:
Posts (Atom)