Adam Hollock
Philadelphia, PA
Adam.Hollock@gmail.com

Click here for a printable copy of my resume.

Education


Drexel University
Master and Bachelor of Science in Electrical Engineering

Competencies

  • Python - Django, Pyramid, CherryPy
  • PHP - Emergence
  • Ruby - Rails
  • .NET - VB, C#
  • SQL - MySQL, SQLite, Alchemy, MSSQL
  • HTML - HTML5
  • CSS - CSS3
  • Javascript - AngularJS, JQuery, Node.js
  • Wordpress, Drupal, Custom CMS creation
  • Bootstrap, Foundation

Work Experience


Nimblelight - Lead Developer
September 2013 - Present
  • Full Stack Development - Everything from design decisions (Photoshop, Mockups) to front end (HTML5, CSS/Sass, Javascript/Jquery) to Back end (PHP, VB & C#.NET, SQL) to managing database schema and architecture (MySQL, MSSQL)
  • Management - I act as project manager and delegate tasks as necessary to a team of developers.
::hollock - Programmer/Web Developer
October 2012 - Present
  • Provide front and back end consultation services for startups and small businesses
  • Create and maintain servers and database architecture using PHP and MySQL
Philadelphia Gas Works - Engineer II/III
July 2011 - Present
  • Researched and implemented solutions to general maintenance problems for a Liquid Natural Gas facility
  • Managed work for unionized work force, contractors, and other plant personnel
PECO Energy/Exelon Corporation - Engineering Co-op
March 2011 - September 2011
  • Developed secondary network power flow model in Matlab using a distribution-based monitoring network
  • Analyzed and designed solutions for transformer and line overloads
Metso Automation - Control System Design Co-op
September 2009 - March 2010
  • Created customizable monitoring and analysis tools using proprietary design software
  • Improved visual basic code for efficiency and user friendliness
Guideworks LLC - Software Quality Assurance Engineer
September, 2008 - March 2009
  • Programmed procedures for simultaneous endurance testing of multiple cable boxes
  • Developed test scripts and troubleshooting processes for software systems
Hi, I'm Adam. Occasionally people call me Jimi. But that's just a crazy nickname.

I'm a programmer, engineer, web developer, and writer living in Philadelphia who has earned my Master's of Science in Computer and Electrical Engineering from Drexel University.

Outside of my professional life, I enjoy cooking, playing video games, reading comic books, doing tai chi and making music. I am an active member of Philadelphia's Reddit community, and can be found regularly at their events.
I'd say I have delusions of grandeur if I didn't have this tendency to act on them.

github linkedin twitter linkedin last.fm
Hi, I'm Adam.
To read more of my writing, visit my blog

03/15/2013

Over the past week or so, I've been brushing up my PHP chops and trying to build a decent portfolio for myself. My first idea was to build a system for people to upload character sheets and game materials for those tabletop games that would require such material. A functional result can be found here.

One of the things that did not seem to come intuitively to me was password storage. I knew straight up that plaintext password storage was bad. I've read every awful article under the sun about it, and having learned PHP from a slightly outdated, if not otherwise fantastic source, of O'Reilly's Head First PHP & MySQL, I was left using algorithms for cryptography that have come and been broken already. Or at least are not the leading method anymore. For reference, it consisted of taking the password and running it through a simple SHA algorithm, a dangerous solution as it was a quick algorithm (meaning there are free tools out there that can break it quickly enough.)

So naturally, I had to adapt. Curiosity leads to research leads to experimentation and implementation. I come from a background of just about nil security. So my goal was to build something super secure. Daunting, but plausible thanks to the incredible, edible internet.

Hours of research later, the long story short is that the commonly accepted crypt algorithm used these days is to salt the passwords, use the Blowfish cipher to hash them, and store that hash in the database.

To go from the beginning, salting is something you do by appending a string to the data to be hashed and stored. For example: I want to store the password 'HoopyFrood' securely. I would salt it first with a value that's global to my application, let's call it '$gargleblaster'. Most salts would benefit from containing random letters, numbers and symbols, but for the sake of the exercise, we'll just go with this.

So you would append this salt to the password somehow, either as a suffix or a prefix so you would get something along the lines of '$gargleblasterHoopyFrood'. This is generally for the purpose of making the password that much more complex and difficult to crack, while the end user doesn't have to remember anything further than his 'HoopyFrood' Another benefit is to sometimes add additional static information to the password, such as a user id number, or even the user name itself. It just serves to make the password more complex.

The next step would be to encrypt it. Using PHP, we have the 'crypt' function available and, as long as your server has the blowfish method supported, you should be good to go. Otherwise, there are a pile of other methods that can be used. One note is that the salt that the blowfish method uses is a bit more complex than our initially planned '$gargleblaster'. It actually requires a specific syntax in order to let the server know that the specific algorithm you wish to use is the blowfish, otherwise it'll choose the closest relevant method.

For the case of blowfish, the salt you wish to use begins with '$2a$', followed by two numbers that represent a cost parameter (Which involves how much time the algorithm will take, higher will become more secure, however will take longer. The standard is 07) followed by another '$', then 22 alphanumeric characters, followed by a final '$'

A couple examples of salts for use with Blowfish (Please don't use these, I just made them up for the sake of this post.)

$2a$07$everydaytheyreoutther$
$2a$10$emakingducktaleswhooo$
Then all that's left is to call our crypt function. For the sake of this simple example, we assume that the user entered data into a form named 'password'

$password = $_POST['password'];

$salt = '$2a$07$everydaytheyreoutther$';
$cryptPass = crypt($password, $salt);
That $cryptPass is what we're going to want to store in our database. Safe, but accessible by the user. And there you have it.

Other notes, this encryption is a one way street. You can only encrypt things, and cannot really decrypt them in a similar way. So as such, if a user forgets his/her password, it's generally easier to just erase the old password, generate a random one, and let them change it altogether. Storing plaintext is beneficial in that you can simply tell the user what his/her password was, but I think the security cost is worth it to just build another script to allow a user to reset their pass to something else altogether.

There are other things to keep in mind, the way we accept $salt is probably not the safest, since it leads itself open to SQL injection. You definitely want to sanitize the value, which I've learned as:

$password = mysqli_real_escape_string($database, trim($_POST['password']));
There is also another layer of protection named stretching, which we covered in a way, but is meant to result in much much longer pre-hashed passwords. Again, the benefit is computation time versus security. There is a point where attempting to crack these passwords with a machine of the current level of technology is an exercise in futility, so you don't want to go crazy and end up with minute long hashing calls.

If you picked up anything that's erroneous or unclear in this post, please let me know. I am a beginner to security myself, but am hoping to learn more.