Vuillemot, Ward W writes: > I log into your web-site as memberA. You kindly leave me a delicious cookie > with my username stored in it. Maybe even my password (I hope not!). Now, > I know that another member, memberB, has special rights to your site. What > is stopping me from editting the cookie to memberB's username and hijacking > their account?
If you can crack Blowfish, IDEA, etc., you are in. Then again you can probably just sniff the network for memberB's username and everybody else's passwords for that matter, even via SSL. Part of bOP is multi-tiered security architecture including something I call "data gateways" to help protect against programmer mistakes. > And if you do store the password information in the > cookie...you are letting each user be compromised either as the cookie is > flung through the Internet ether, or minimally on their own computer where > someone else can easily access the cookies. If you have access to someone's cookie file, you probably can log their keystrokes. Contact your local spy agency for more information on how to do this. > With sessionID, you have an ID and information that is checksum'd. Sessions and user IDs are equivalent. They are called "credentials" which allow access to a system. There's no fundamental difference between hijacking a session or stealing a user id/password. > If I wanted to delete a user and ensure they immediately lost all access, it > is rather trivial to go through all active sessions in the db, see if the > user I am deleting matches the username in the session information, and if > so delete the session record. Denormalization is the root of all evil. The extra step involves more code, more bugs, and more system resources. Other than that, you're right. You can do this, but the question I ask: Do you need to? Rob
