It’s been a little while but I just realized that I did not post these here. The slides for my presentation, “Creating “Secure” PHP Applications, Part 2, Server Hardening” are on SlideShare at the link below.
It’s been a little while but I just realized that I did not post these here. The slides for my presentation, “Creating “Secure” PHP Applications, Part 1, Explicit Code & QA” are on SlideShare at the link below.
This is not a complete article on how to create a secure PHP application but rather, the outline for a talk I’ve been planning for some time. Yes, there have been talks on this topic in the past but they either had flaws or were missing some essential pieces. My goal was to provide a complete list of application security concerns and explain how you go about dealing with them in PHP. Of course, much of the context is missing but it wouldn’t be a very good talk if I wrote it all down, now would it? I’ve decided to publish it in hopes that it will force me to give the talk sometime soon.
As mentioned by some of the more well-known PHP talking heads in their responses, there has been quite a bit of PHP bashing going around lately. Each of them provided great reasons for using PHP. And while they came close, they didn’t quite cover the reasons I continually choose it over others. Or at least, they expressed it differently.
After accepting the fact that Git is likely going to supplant SVN, I decided to hunker down and figure out how to actually USE the tool rather than fight with it every time I had to interact with it. Well, my foray into Git has often reminded me of a very similar experience I had when learning Vim: utter frustration. Each time I dug into Git’s man pages and internals, I felt more confused than when I started and told myself, “just live with it”. Well, as with Vim, as time has gone by, I’ve learned things which have made Git infinitely easier to live with and I want to share them with you.
Some hype has been going around the web lately related to the use of Bcrypt and how it opens you up to denial-of-service attacks. Now, to the seasoned developer, this is a completely ridiculous notion. As developers, we think about how and when resources will be consumed on a daily basis.
To be fair, one of the videos I saw was targeting “inexperienced developers” and didn’t offer many solutions to the issue. I wanted to chime in with some simple measures to implement which will help deter attackers from using your derivation function against you:
- Check for a valid user record before hashing the password
- Store the last log-in attempt time-stamp for each user
- Store the number of failed log-in attempts for each user
- Write the following time delay function into your log-in routine before the password is hashed:
- If failed log-in attempts > 1
- Wait until (failed log-in attempts ^ 2) seconds after the last failed log-in attempt before allowing the password to be hashed again
- If failed log-in attempts > 1
- Reset the number of failed log-in attempts after each successful log-in
That’s it. Simple.
Thanks for stopping by.
Often, I’m utterly depressed by the state my industry (software development) and then human nature in general. Then, every once once in a while, I’ll run across a group or a study, see what they are trying to accomplish, and it renews my enthusiasm.
This week, the number of instances of the later has been greater than the number of instances of the former :)
Here are the examples:
It doesn’t get a whole lot better than this.
Except it does! Shortly after I posted this, my wife accompanied my 2-year-old daughter out who brought me a chocolate chip muffin :)
In anticipation of the upcoming move, I scrubbed our kitchen floor on my hands and knees with a sponge. It’s amazing how much cleaner it gets as opposed to a mop or a Swiffer. The most intriguing aspect of the whole thing was the distinct odor of garlic being released as I moved across the floor. Now it smells like I just got done cooking!
Oh, which could it be?
Click here for a larger version.