While working on testing out my new Cryptography library (appropriately called PHP-CryptLib), I ran into a rather interesting problem. How do you unit test a method that interacts with the file-system? Traditionally, this problem has been solved by either not testing the method or creating temporary directory structures, testing, and then deleting the temporary directories. There has to be a better way. And as it turns out there is!

This is the first post in a multiple part series on Web Application Security. Throughout this series, we will take a look at some of the different aspects of security as it relates to web applications and some techniques on how to mitigate them. Before we can dive into the finer details of Security, we must define what it is and what it is not. After that, we’ll talk about some foundational pieces that will drive and support the rest of the series.

I recently read a post entitled Dependency Injection: An Analogy, and I think it does a pretty good job explaining two of the types of Dependency Injection. I really like the theme, and feel it really brings down the topic of DI to easy to understand language. The only problem with it that I can see is that there are actually 4 flavors of DI available to us. The other two flavors aren’t even touched in that post. So let me expand on that theme a bit here (Borrowing the same core analogy base from that post):

Quite often we see people talking about the best way to approach a problem. Usually this involves taking a relatively simple concept and making it fairly complicated to make it as flexible and maintainable as possible. While I’m all for maintainability, I think that sometimes we miss the point that it all depends on context. It seems like most people don’t understand the difference between good and good enough.

Part of being a developer is making design decisions based on conflicting goals. Our job is to choose the line that’s appropriate based upon our experience and the needs of what we’re doing. But there-in lies the problem: How do we know where that line really is? How do we know when we’ve actually reached the point of good enough?

Here’s a quick link to a StackOverflow answer that I wrote explaining password hashing.

A key feature of cryptographic hash functions is that they should be very fast to create, and very difficult/slow to reverse (so much so that it’s practically impossible). This poses a problem with passwords. If you store sha512(password), you’re not doing a thing to guard against rainbow tables or brute force attacks. Remember, the hash function was designed for speed. So it’s trivial for an attacker to just run a dictionary through the hash function and test each result.

I think it does a pretty good job explaining hashing and encryption, and is worth sharing