I value privacy, and to get it I use encryption. To use encryption on a website, you can use SSL, but to use SSL you need a certificate, and to have the certificate match the domain, you need a separate IP number for each certificate / domain. That's no good!
Why bother with so many domains? For branding purposes of course! :-)
Choose your own adventure:* Username and password in one form using http digest* Username on one page, password on next, can use username to retrieve salt to encrypt password during transmission, non-existent users get a consistent yet randomly generated salt result
There are advantages to using web server based digest authentication alongside an application:* you can let the webserver quickly serve private information that don't require complex application logic, like images, otherwise you'd have to feed them through the scripting language, which is potentially bad for performance* you can improve the security of the transmission of the password over unencrypted channels* the server is protected even if the script / application malfunctions
Once the user has authenticated using http digest authentication, the application can go ahead and start a session for the user, as well as do its own authentication, and initialize a permissions roster for that user.
Like some have suggested, I don't recommend having your PHP or scripting language handle the digest authentication on its own. This won't give you as many benefits as having both the server and the scripting language manage the authentication and session.
One problem I encountered using http digest is that the password MUST be stored in an MD5 hash (no salt) on the server (along with the realm and the username). This is incompatible with other authentication mechanisms, which use part of the hashed password as the salt used to calculate the password hash. That is a better way to store the password, but it isn't implemented in the digest format. Furthermore, if you wanted to provide flexible access to authenticate both against the web server and the scripted application, you'd likely need to use Apache, as it has the ability to authenticate via pam, and thus all of its modules.
Seeing how we're balancing design with practical needs, I'm starting to think that the best practice is to store passwords in multiple formats.
The point to all this is to setup a system that is reasonably secure. First off, storing passwords in cleartext in a database is a bad idea, it causes many legitimate bad practices to occur, like systems administrators retrieving passwords for users. Isn't it nice to say - "I don't know your password, it is hashed in the database". Beyond that, while it is possible to crack md5 based algorithms, it isn't practical or legal (though I am not a lawyer!). Depending on your use, you should consider the other options as well, like SSL and VPNs.