Re: Cookies/Remeber password

Webmaster wrote: > > Aren't cookies changed when response is coming from > web server that created them? > So was big deal if someone copy a cookie from my pc? > Cookies are a two way thing: 1) They originate from the web server. 2) They are sent from your browser TO the webserver. The problem is that when sites use cookies to hold authentication information such as userid and passwords, then the security of the user's account is only as good as the security of the cookie. If the cookie file can be simply copied, then the copy of the cookie can be loaded into another browser's workspace. When THAT browser visits the web server in question, the cookie will be sent to the web server, and the application will think "hey...i know you based on your cookie; sure, I'll give you your account data..." Basically, NEVER NEVER NEVER put authentication information into cookies. It's not secure. If you want to use cookies for tracking a user login, do the following: a) Create a login page. When the user enters the proper credentials (e.g. userid and password), create a unique session identifier. Build a unique assocation between the session identifier and the user (e.g. the session identifier might be a file in a "session" directory, that contains the username. b) Put a time limit on how long the session is good for (e.g. 15 minutes). c) Send the session identifier in the cookie to the browser. d) On subsequent page requests, look at the session identifier, and check your local data to see if the session is valid. e) Update the timestamp on the session so that the user is considered to still be active, thus resetting the 15 minute timer in b) above. Additional things you can do to enhance your security: 1) When you create the session for the user, make note of the first two octets of the IP address. Disallow any requests that don't come from there. You can go so far as 3 octets, and it will USUALLY work. The problem is, some users surf through proxies that are load balanced, and the same user might show up with one IP addr on one request, and another iP addr on the next request. These will virtually always be in the same class B space. (In fact, I've never seen them in different class C's, to be honest). 2) In the local session, store the browser agent string. If a subsequent page comes in with a different browser ident, disallow it. 3) Put the session over SSL, thereby preventing cookies from being sniffed. 4) On SSL sessions, mark the cookie as "secure", thus preventing the cookie from being cached to the browser's disk. Not all of these are fool proof; i.e. 1 and 2 above are security by obscurity. 3 and 4 are good practices whenever you are building a login mechanism. However, no matter what you do, it all boils down to understanding what the security exposures are, and how badly you would be impacted by a security breach (and how much it would cost in good development up front to ensure that the breach doesn't occur.) For what it's worth, we always: a) Put sessions over SSL. Certificates are just too cheap to not be doing that. b) Never store passwords in cookies. c) Always tag cookies as secure d) Always do a cross check against the browser agent string. Cheers, hope this helps. Thomas -- ------------------------------------------------------------ Thomas Reinke Tel: (905) 331-2260 Director of Technology Fax: (905) 331-2504 E-Soft Inc. http://www.e-softinc.com Publishers of SecuritySpace http://www.securityspace.com