Good eye, Ovid, and thanks for the reply. The mid is a member ID number that's returned from the get_member sub. It does it's work where the "..." snip is.

Right now the mid comes right out of a cookie, so yes, you could edit your cookie and be logged in as whoever you chose. But this is nowhere near production yet; here are my plans:

First, I may use session cookies, which will help a little.

Second, I've got a member_info table, then a logged_in_members table with 3 columns: member id, login time, and hash. The hash is some sort of one-way random-looking collection of garbage characters (MD5, maybe), and it's what I'm going to store in the cookie. You login via SSL, then the cookie is set with said hash (different for every login). That'll be checked at each page request against the logged_in_members table to authenticate, then blown away from that table when (a) the user logs out, or (b) x time has passed.

Regardless of what parameters are passed to the script, mid is set every time by the script itself - either a member id or 0 - it's never accepted as a CGI param.

Potential problems: I'm not likely to run the entire site under SSL, so someone could sniff the hash value as it's being sent over HTTP to the server. This would allow them access to the member's info (no CC #s, ever), and allow them to request a password and/or email address change. Password and email changes will have to be authenticated by replying to an email sent from the server (or something similar, e.g. navigating to a link in that email which contains a "?verify=<hash>"). So the attacker would not only have to sniff the hash and setup their own cookie, but intercept the email coming from the server and reply to it. I know this is possible, but I consider it unlikely enough that the risk is acceptable.

I don't know if this is the best possible method, but it's one I've seen recommended by people who seem to know what they're doing. I'm not a security expert, but it seems pretty good to me. What do you think?
--
man with no legs, inc.