Showing posts from 2018

Configuring a Password Cracking Computer

“Be willing to be a beginner every single morning.” —Meister Eckhart Disclaimer: While the reason I'm writing this is because I was lucky enough to win a new cracking rig from  Netmux's   Hash Crack Challenge , I want to state for the record that he never asked me to blog about it, and all of the good things I say are 100% of my own choosing and not contingent on me receiving any prize. 2nd Disclaimer: I plan on this being a "living" blog entry as I continue to update and use my new computer. Since install procedures change over time, for the record I started to perform my install on September 7th 2018. I'll try to date my entries as I write them to help anyone trying to follow this so they can estimate how useful these instructions are. ChangeLog: September 12, 2018, (rearranged sections, added MDXFind, updated installing OpenCL instructions) September 7, 2018 (Computer Arrives): Wow, I suddenly and unexpectedly found myself in possession of a ded

Netmux's Hash Crack Challenge Writeup

"Good luck is when opportunity meets preparation, while bad luck is when lack of preparation meets reality"  - Eliyahu Goldratt This last week I participated in Netmux's Hash Crack Challenge , and this happened: HASH CRACK CHALLENGE Hash #2 has been cracked by @lakiw . Congrats to our winner and thanks to everyone that participated! It was a bumpy ride but a lot of fun to create and host. Thanks again to everyone and look for the final write-up in the coming days! — Netmux (@netmux) September 1, 2018 So I figured the least I could do was make a blog posting about it along with my analysis of Netmux's One Time Grids , which the challenge was based on. TLDR/Bottom Line(s) Up Front (BLUF):  I was lucky enough to be checking Twitter right when Netmux posted his final hint, and that was the only reason I won. As to the security of One Time Grids, they share a lot of similarities to other password books, which can be both good or bad depending on your threat mode

Creating Long Term SSL Certificates

"It's constantly fascinating for me that something that feels absolutely right one year, 12 months later feels like the wrong thing to do." -- Damian Lewis Often I find myself having to create my own SSL certificates. Be it an internal web-server, or two scripts that need to communicate to each other, SSL is the easiest way to encrypt network traffic. Unfortunately it's also one of the most dangerous encryption methods. If you make a mistake setting it up it usually works ... at least for a little while. Ignoring the client SSL checks for now, (hint if your script is using SSL and it works the first time, you probably are not checking SSL correctly), one area of danger is having your SSL certificates expire. As an example of that, recently every Oculus Rift broke because a code signing certificate expired. Admittedly this was a different type of certificate, but the same thing tends to happen with internal SSL deployments. People do not remember to update them, a