Etienne Marcotte <[EMAIL PROTECTED]> writes: > I have a webpage where a user logs in to get administrative options. > The main admin page directs to different sections (perl scripts) for > different table manipulations of the database [...] > > What are your comments regarding those methods / do you suggest > something else $ which one would you use / speed?
This depends on how much security you require and what threats and risks you are trying to minimize. > - Users logs in, when choosing an option, values for username, pass, > userID, etc are sent to the new script via POST in a form. This is bad because you are sending the password over the network with each call. If you are not encrypting the information, then someone sniffing your network can get the username/password. Even if encrypting the information somehow, repeatedly submitting passwords over the network is not recommended. The password, etc. is also viewable in the page source to anyone using the browser, which includes the legitimate user and anyone who might pass by their computer while they go off to fetch a cup of coffee. > - Users logs in, script sets cookie, when choosing an option, values for > username, pass, userID, etc are read from the cookie by the called > script (so the link is not a form with hidden fields but only a link to > the script name) Reread "This is bad..." paragraph above. Same thing applies here. Substitute "cookie file" for "page source" in the "The password.." paragraph above. Same thing applies here. A better approach is to transmit the username/password encrypted just the first time. Verify this information the first time and create a unique non-forgeable identifier (or token or cookie) containing no information about the username or password; someone should not be able to obtain the username/password from this identifier or create an identifier that is valid without logging in. The identifier might be stored in a DB along with the user id. Use this identifier for confirming user actions during this session; if the identifier is stolen, than the thief only has access for this one session. You might also limit access with this identifier from a single IP address, if users will always have a single IP address in a session; then a stolen identifier can only be used on the same machine as the original user, which might make it less useful. There are various ways to do the above. Talk to your local security expert for more ideas. + Richard J. Barbalace <[EMAIL PROTECTED]> Cambridge, Massachusetts, USA -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
