On PHPMaster.com they've posted a new tutorial by Sean Hudgston that helps you understand HTTP digest authentication, a simple way to authenticate a user or script against your application.

Digest Access Authentication is one method that a client and server can use to exchange credentials over HTTP. This method uses a combination of the password and other bits of information to create an MD5 hash which is then sent to the server to authenticate. Sending a hash avoids the problems with sending a password in clear text, a shortfall of Basic Access Authentication.

He starts out by looking at the "basic authentication" mechanism that's built into most web servers and points out that it has a major flaw - sending the username/password in (pretty much) plain text. Digest, on the other hand, uses a MD5 hash created from a few pieces of information including username, realm and request method. The result is sent as a header back to the server that can then be parsed by PHP. He also talks about improving on the basic version of the digest method using the qop, nc, and cnonce optional parameters.

On Mike Dalisay's site there's a recent post showing how to use the Phpass tool to salt, hash and store passowrd data in your application.

I think the main reason why we have to hash passwords is to prevent passwords from being stolen or compromised. You see, even if someone steal your database, they will never read your actual or cleartext password. I know that some PHP frameworks or CMS already provide this functionality, but I believe that it is important for us to know how its implementation can be made.

His sample application stores the user data in a MySQL database and does the salting+hashing at the time of the request. It uses a hard-coded salt and a value of 8 for the hashing/stretching. Screenshots of each page in the example application are also included.

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.

On Reddit.com there's a good conversation going on in the PHP category about login security and best practices surrounding it.

So I was handed an ancient project which was up to me to fix / improve. About a week later I am about done but there is 1 thing I left...Login security. As it is now, it's just md5(password) that's saved in the database. Better then nothing, but far from good enough. My plan was to have a constant pepper in the class which handles the logins, then do something like crypt(pepper . $password) to store it, since that should generate a random salt and is slower then sha1 / md5 / etc. I feel this should be save enough, do any of you have any ideas on how to improve it (without non-standard extensions)?

There's lots of comments so far and a lot of them are following along the same lines - use a better method of encryption, something like crypt with Blowfish or something similar as well as some hashing (like HMAC).

Michael Nitschinger has a new post for the Lithium framework users out there - a quick tutorial about encrypting your session information with the new built in "Encrypt" strategy feature.

If you check out the master branch, you can use the new Encrypt strategy to encrypt your session data automatically. This means that you can read and write session data in cleartext and they will be encrypted on the fly before getting stored (in a cookie, for example).

You'll need the mcrypt extension installed for it to work correctly, but it makes storing the encrypted version of your data more or less automatic. Just set up your Session configuration to use it as a strategy and any time you call a "read" or "write" the hard work is handled for you. For those more interests in what's "under the hood" he goes on to talk about how the strategy works, what cipher it uses by default, how to change it and the default string to use in hashing.

In response to some of the comments being made about the hash table Denial of Service attack recently posted Freek Lijten has posted his thoughts about the real problem with the whole situation - how it was handled by the communities involved.

Interesting they may be, but I want to address what in my opinion is the real problem: The way the communication around it was handled by different projects and the fact that the exploit could still exist at all. [...] In the presentation Wälde and Klink talk about their disclosure process. The PHP project had them wait 3 weeks for a first response while this is obviously a serious matter.

He argues that things like a commit message mentioning a DoS prevention fix instead of just mentioning the fix have the potential to do more harm than good. He also points out that other communities were notified of the problem (like Python) and some still haven't responded to the issue.

This attack was the result of good research and it is important that it is disclosed. More importantly however is the fact that organisation got by with years of not noticing it and even worse, reacted very poor after being informed. I can't say I have a ready solution to avoid these kind of things in the future, perhaps that will prove to be an interesting discussion.

In a quick note from the PHP.net site, they have a warning for those running PHP 5.3.7 (the most recent release) - there's a bug that's serious enough (with crypt) to where upgrades should probably wait until 5.3.8.

Due to unfortunate issues with 5.3.7 (see bug#55439) users should wait with upgrading until 5.3.8 will be released (expected in few days).

The issue causes the crypt() function to only return the (MD5-only) salt it was given instead of the correctly hashed string. If you need to replace this immediately, you can pull the latest from the snaps site (or binaries for Windows). Keep an eye out for PHP 5.3.8 in the near future.

In a recent post Marcus Bointon looks at a hashing method that's not one as commonly used by developers as the usual base64 - base-62 encoding that plays a bit nicer with things like URLs and emails due to the character set it allows.

There's a really horrible bug (though they won't call it that!) in Apache's mod_rewrite that means that urlencoded inputs in rewrites get unescaped in their transformation to output patterns. The bug actually remains unfixed, though a workaround first appeared in Apache 2.2.12. [...] Base-62 is interesting as it can be made safe for use in URLs, DNS, email addresses and pathnames, unlike any available encoding of base-64, as it only includes [0-9A-Za-z].

He originally wrote his own parser, but notes that now the BCMath and gmp extensions make it much simpler, just a call to gmp_strval with gmp_init. This method works, but it's still not quite all he wanted so he created his own encoder to do the job.

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).

In a new post to his blog today Jordi Boggiano talks about a task that can trip up some developers when they're trying to secure parts of their site or just create one-time use tokens - making unpredictable hashes.

If you [override the default session handlers], unless you want to entrust PHP's core to do it, one thing you will have to take care of is generating unique session ids to send as a cookie to your users, allowing the session to persist. Other common use cases for such unique hashes is to generate CSRF tokens to insert in forms or URLs, and finally authentication tokens for email validation or such.

He talks about how we, as humans, aren't very good at figuring out true randomness and that hashing the information only adds to the problem. He mentions how some of the random functions in PHP aren't all that random and that there's a better way to really generate good values. He's come up with a solution (his "generateUniqueId" function) that tries to generate entropy from OpenSSL or from the COM extension or from the "/dev/urandom" on unix-based systems. It's then hashed and sent back out the other side for easy use.