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.

On PHPMaster.com there's a new tutorial that wants to help you keep your application and users a bit safer - a guide to password hashing for PHP applications.

You must always think about security. If passwords are stored in plain text, what happens if an attacker gains access to your database? He can easily read all of the users’ passwords. That’s why we use a technique called password hashing to prevent attackers from getting user passwords. In this article you’ll learn how to store the passwords securely in the database so that, even if your database falls into wrong hands, no damage will be done.

He starts off describing what password hashing is and why it's important (and better than it's plain-text alternative). He gives some examples of using some of the built-in hashing functions PHP has to offer to generate the hashes. He starts with md5/sha1 (note, these are not recommended) but moves into more effective options like sha256, salted hashing and even bcrypting passwords with crypt.

Be sure to check out the comments for other security concerns and links to suggested tools and resources.

Sameer Borate, in the wake of having security issues with his site, has posted a hint you could use to help detect when something has changed in important files in your application by checking their hash.

Today a couple of hours back my site got compromised. Not much changes to the code, but the .htacces was changed and some code [...] was added to the .htaccess file, which redirected the traffic coming from search engines to a malware site. It has now been removed and to prevent any such changes to the .htaccess file in the future, I’ve written a small php script that compares the hash (SHA1) of the two major files that usually get compromised and compare them to the one originally stored.

It's not a preventative measure by any means, but it can help you keep track of if something's changed. Several issues have popped up in the major blogging engines that allow for changes to be made directly to files. These changes result in the sha hash to be different and can be used to trigger a security alert. His sample code shows a basic call to mail an alert, but it could be as complex as you'd like (possibly even logging to a database or the like).

On DevShed there's a new tutorial looking at user management in a PHP application including looks at data validation and encrypting passwords.

In this article we will look at how to create a secure user management module. No user authentication or user management script can ever be one hundred percent secure, but we can try to use the tools that are available to us to their maximum, and thereby make it difficult for malicious users to hack our scripts.

They include example scripts showing how to validate user input - length, alpha, empty or not and if its numeric or not. They look at encryption with the sha1() technique, comparing the user's input, hashed, to the key already stored.

Paul Reinheimer has a suggestion on how to improve the PHP manual to be an even better resource - enhancing the "see also".

Something I'd like to see in PHP is a little more in the See Also section. They're pretty good, but it's not quite as spider-web like as I'd like. For example, yesterday I added a few links from md5() and sha1() to hash(). Lot of people know about md5() and sha1() within PHP, but I find hash() is rather unknown overall, which is a pity as it exposes a tone of different hashing algorithms.

You can see an example of his updates in the md5 manual page linking it to sha1_file, crc32, sha1 and the hash functions.

On his blog, Jonathan Street has posted some "random thoughts" on generating random (or not so random) strings in PHP.

Humans are astoundingly bad at being random and I just slapped the keyboard a few times until I felt I had the required 16 characters. Writing some code to produce a fairly random string is incredibly easy. I've easily done it a dozen times or more. Though only because it is easier to re-write it than to find where I put the last one

He gives two examples that work, but aren't the best possibilities for making truly random strings - one using mt_rand to select a random character from a string and the other using the same idea but instead using the char() function to replace the string of characters.

His other examples include the use of the uniqid function with the more_entropy setting enabled and an md5 or sha1 hash (for which he gives positives and negtives).

Ryan Malesevich is taking a break from his look at some handy WordPress packages to share a small series on how to move from using MD5 hashes out to SHA-1 hashes for passwords in a MySQL database. He's posted part one today.

What if you're using MD5 in your web application and want to switch over to another encryption method. It's actually not that hard and I plan to cover them in this multi-part tutorial (I know I planned on writing this months ago, but it's better late then never). In this first part I plan on going over updating the database structure and a 'pseudo-code' of what will need to be done.

As mentioned, he gives the outline (pseudo-code) of how the process will work - basically, creating an SHA1 hash of the MD5 and the username in a "newpassword" column added to your database.

Ryan Malesevich is taking a break from his look at some handy WordPress packages to share a small series on how to move from using MD5 hashes out to SHA-1 hashes for passwords in a MySQL database. He's posted part one today.

What if you're using MD5 in your web application and want to switch over to another encryption method. It's actually not that hard and I plan to cover them in this multi-part tutorial (I know I planned on writing this months ago, but it's better late then never). In this first part I plan on going over updating the database structure and a 'pseudo-code' of what will need to be done.

As mentioned, he gives the outline (pseudo-code) of how the process will work - basically, creating an SHA1 hash of the MD5 and the username in a "newpassword" column added to your database.

PHPit.net is back today with another new tutorial - this time it concerns the safe handling of passwords in your PHP scripts.

If you're ever going to create a script that involves users or passwords, which is very likely, you'll probably run across security issues with handling the passwords. You can't just store the passwords in clear text in your database, and great care must be used when managing the passwords (for example during login).

In this article I will show you everything that you have to think about when handling passwords in PHP, and how to solve some common problems.

They offer suggestions like storying them hashed (md5 or sha1), protecting them with a salt, SSL certificates, and how to manage their use with things like cookies and sessions.

PHPit.net is back today with another new tutorial - this time it concerns the safe handling of passwords in your PHP scripts.

If you're ever going to create a script that involves users or passwords, which is very likely, you'll probably run across security issues with handling the passwords. You can't just store the passwords in clear text in your database, and great care must be used when managing the passwords (for example during login).

In this article I will show you everything that you have to think about when handling passwords in PHP, and how to solve some common problems.

They offer suggestions like storying them hashed (md5 or sha1), protecting them with a salt, SSL certificates, and how to manage their use with things like cookies and sessions.