Chris Cornutt
Safe(r) Passwords in PHP
Using bycrpt for safer password storage
As anyone whose used a web applications knows, the password is still the go-to form of identification. Sure, there have been lots of improvements in the world of identify over the last few years, but there’s still a constant flow of applications and websites that rely on this tried and true method of protection. Unfortunately, because it represents a single point of failure, it’s actually one of the least secure methods for providing your user is why they say they are.
There’s been a recent resurgence in alternate technologies to help protect your application’s users including a wide variety of two-factor solutions and things like federated identify providers. People are understanding more and more that a simple password isn’t enough. We see stories almost daily of some major company or group being hacked because of either bad passwords or bad password storage practices. Unfortunately, there’s only a limited amount of things you can do for the former (like more effective password policies), but there is a way to help with the second. It’s surprising to find out just how many companies and applications have made poor choices when it comes to how they protect their users’ passwords. There are even some that have made the disastrous choice to store them as plain text (it makes me cringe just thinking about it).
Preventing Problems in PHP Security
Taking a look at the usual suspects: SQLi, XSS & CSRF
As any PHP developer that’s been around for a while will tell you, there’s a certain kind of stigma that comes with the language. They’ll hear it from their peers using other languages that PHP is “sloppy” or that “it’s just a scripting language, not a real one.” There’s one other that seems to follow the language around as well—that it’s insecure. Sure, PHP’s not without its problems—but any language is going to have its share. Ruby’s had several major vulnerabilities in the press lately and Java has definitely had its own list over its extensive lifetime. People put down PHP for not being secure, but they forget that it’s not the language that makes for insecure code, it’s the developer.
PHP, by its nature is “meant to die” at the end of every request, so the developers don’t have to worry about some things that more persistent languages do. There’s still some common dangers, though, that you as a PHP developer should be aware of. The most common ones come from the well known OWASP Top 10 list. Here’s a quick look at how to help prevent just a few: