On the Dreamincode.com forum there's an interesting approach mentioned for security login forms from brute-force attacks using a queueing system rather than the usual real-time requests.

Login forms in online systems are often easy targets for brute-force attacks; attacks designed to go through all possible values (or at least all probable values) for a password to "guess" a correct one. Securing your forms from such attacks is important, but it can be tricky to do in an effective manner without adversely affecting the user experience of your normal user. The method I am suggesting in this article is that of queuing login attempts in an effort to limit how many attempts an attacker can execute per second. [...] So, how do we implement this in PHP?

He suggests using a MySQL-based queueing system (but it could easily be replaced with one of the *MQ types) that tracks users versus login attempts. He's put together a library that handles the storage and login attempt management. He takes some time to explain the functionality of the class and how to put it to use.

In a recent post to his site Sherif Ramadan looks at the topic of password hashing and why most developers are (still) doing it wrong. He notes that "fixing the people" and their mindset about hashing/salting is much harder than just fixing the code.

Beyond just writing code I also have to solve some very tough problems on a regular basis. Some of which don’t stem from code at all, but from the people behind the code. Fixing code is easy for me (computers just do what I tell them to do), but fixing people proves to be a lot more challenging. Unfortunately some people are of the mindset that they aren’t wrong simply because they’ve never been proven wrong before. To some people being proven wrong goes beyond just words. Some of us are a lot more stubborn than others and so explaining something may not be enough. This is called the wisdom of humility.

He points out that even those that immediately think "rainbow tables" when they think about md5 hashing are behind the times. Most processing methods, including the use of a GPU, can be used much more effectively and don't require the overhead of the large tables. He illustrates with a "random" md5 generator that outputs around 916 million variations. With a GPU running 4k million per second, this kind of cracking won't take long. He also talks about salts and how they can help the situation - but not just append it, hash with it.

It’s usually the result of several underlying factors that people end up making poor choices about security. Some times it’s due to incompetence. Other time it’s due to politics. Whatever the reasons are they are never excusable, because there are better alternatives out there and it’s not as though they are more difficult or less available than others. So there really are no good reasons [not to do it] here.

Joshua Thijssen has a new post to his blog looking at password hashing and salting - something that, really, should always be done to help protect your site's user information.

Even though it is true in effect that using a salt increases the overall security of your hashes BUT it’s not only because your passwords are longer. There is a another (maybe even more important) factor that comes into play, namely the fact they are more secure against rainbow table attacks, but that depends on HOW you season your hashes. Season it incorrectly, and you gain nothing in security even though you think you did...

He gets into some of the details about hashing your information, how you can break that hash easily and how salting your information can help reduce that risk. He also points out things like rainbow tables and brute force that could still break these salted passwords.He recommends using a different method than a single salt - a different one for each user with a part stored in plain-text along with the user record.

DevShed is continuing their series on PHP security with this new tutorial focusing on the security surrounding user authentication.

So far we have covered security vulnerabilities that involve form data, databases and file systems. In this article we are going to look at authentication and the security issues around it. We will also look at some of the most common attacks in this field.

They start things off by describing two of the usual authentication methods - via a login form and through HTTP authentication. They start poking a few holes by looking at some of the common attacks for these approaches including two popular ones - brute force attacks and password sniffing.

DevShed is continuing their series on PHP security with this new tutorial focusing on the security surrounding user authentication.

So far we have covered security vulnerabilities that involve form data, databases and file systems. In this article we are going to look at authentication and the security issues around it. We will also look at some of the most common attacks in this field.

They start things off by describing two of the usual authentication methods - via a login form and through HTTP authentication. They start poking a few holes by looking at some of the common attacks for these approaches including two popular ones - brute force attacks and password sniffing.