superdezign wrote:The Phoenix wrote:Make sure you aren't sending the password in cleartext to test it. If you are going to test the password (and there are many good reasons not to), do it client-side via javascript.
Whoa, that is a fantastic suggestion. I've never even considered it before. However, what about when JavaScript is disabled? Do you check against this in PHP (likely in a posted value) to determine whether or not it was processed prior to posting?
Its a tough one! Here's my thinking about it.
If a user comes to my site, and doesn't know better (doesn't manually change his settings),
he/she is the user that needs protecting the most. So, by default, I use javascript to encrypt the password before transmission.
If, on the other hand, a user who knows what he/she is doing, and disabled javascript? Well, they are smart enough to disable javascript, and should be smart enough to avoid the risks of shared passwords.
What I do is I check the length of the password sent. If it encrypted, its 40 or 56 characters or whatever. If its not encrypted, its likely to be limited to the length of the text field (conveniently set smaller than the encrypted length).
If so, I put up a results page that warns that with javascript disabled, the passwords are sent in the clear,
but I still attempt to authenticate the user, by doing the encryption of the submitted password server side.
Best of both worlds, and protects the largest number of users, I think.
I'm welcome to discussion about whether its non-ideal. The one real bummer about it is that you can't (easily/securely) allow users to save their passwords via the browser controls since it replaces the textfield entry with the js encrypted version before submission.