But the cookie shouldn't depend on the password itself. The cookie should be more like a cryptographic hash of something including the hashed password. So sniffing the cookie would not get you very far. You'd have to learn the "secret" string and then reverse a hash function and that would then only get you the hashed password.
The 'login' page should be https://. I've long wanted that. That'd also mean getting rid of the "login nodelet".
Also, a good password hashing function takes significant CPU time. There is a balance to be struck there. Making op=login a very convenient denial-of-service attack point is a bad idea. We might want to implement a "you recently tried to log in (from this IP address or for this username), please wait before trying again" response, which means we only need to worry about attacks from botnets. Surely that would never happen. /:
I'm pretty sure you are aware of this, but to avoid confusion from people reading this later...
You'd have to learn the "secret" string and then reverse a hash function and that would then only get you the hashed password.
If we are really talking about the cookie being a cryptographic hash of something and a hashed password, the phrase reverse the hash describes an extremely hard problem. Reversing any cryptographic hash should be computationally infeasible.