|No such thing as a small change|
I know I'm coming late to the dance with this, but I've been giving it some thought. When we speak of security, we are usually talking about one or two different things; authentication and encryption. The http protocol isn't really designed for security, it is designed for functionality. Security is left to the implementor.
Putting aside https for the moment (which really is the best implementation of http when it comes to both of these topics) we need to look at what we can do to fulfill both of these points. In the case of a login, we are actually in the process of trying to authenticate our user, which means there isn't a trust system in place between the two parties.
My thought about this would be that when a user first subscribes to our system, they are required to provide they're public key. Also, the monks public key is provided on the site. Now, when someone logs in, they first encrypt their pass-phrase (We're talking security here, so let's go all the way) with the monks public key, insert it into the pass-phrase text area and submit.
PM has its private key, decrypts the pass-phrase and registers it. And, of course, monks must repeat this cycle if they must login. Of course we can still use our current cookie method of remembering who we are to limit the need for this. Beware, however, if we are at a location that doesn't have a tool for encryption, we won't be able to login. If a pass-phrase is lost, a new one can be generated and emailed to the monk using their public key. The system is complete.
This brings me back to https. This protocol has the two pieces of security that I mentioned above. The authentication portion of https is a safeguard against some site saying they are PM when they're really not and stealing whatever informaiton we are sending to one another. The simplist method of encrypting passwords would be to implement the login only in https without a third party certificate. All we are truly talking about here is encrypting passwords and sending them securely, not authenticating one or both of the parties involved. On most webservers you can allow the server to generate it's own certificate for the sake of encryption, and only if we were going to implement a shopping cart or something similar would the need for a third party cert really be necessary.
Those are just some thoughts I've had about this topic, your mileage may vary, this offer only good to the first ten callers, some restrictions may apply.