Re: security diff between hidden fields and cookies
On Mon, 28 Mar 2005 15:12:06 -0500, Thomas, Mark - BLS CTR <[EMAIL PROTECTED]> wrote: > > I would like to get some opinions on what is safter, > > hidden fields or cookies? > > You might be surprised to hear both are equally insecure. In either case, > you're sending data to a browser, and you're assuming the browser will send > it back to you unchanged. Yet either can be manipulated. > > The best thing to do is avoid sending important data to the browser > altogether. You can use a sessionID as the previous poster mentions, but be > sure you keep in mind that the SessionID can be manipulated so make sure you > build the proper controls in place to handle that. > This is a VERY interesting thread- It all depends on your needs, but security is getting more and more of a legal issue so ... Most websites include both... cookies for the session handling and hidden fields for the login handshake. Use an SSL/TLS web page for login/signup. everything else is OK to use in cookies, IF there are no passwords "in the clear". That brings up the basic philosophy you should follow; don't leave "tracks" in your client-level HTML code that a bad person can follow to get into your website no decryption logic or HTML comments like "// decode base64 here" (I know it sounds dumb, but I admit; mea culpa). If this thread gets deeper, maybe we can all have a security discussion. kevindot ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
RE: security diff between hidden fields and cookies
> I would like to get some opinions on what is safter, > hidden fields or cookies? You might be surprised to hear both are equally insecure. In either case, you're sending data to a browser, and you're assuming the browser will send it back to you unchanged. Yet either can be manipulated. The best thing to do is avoid sending important data to the browser altogether. You can use a sessionID as the previous poster mentions, but be sure you keep in mind that the SessionID can be manipulated so make sure you build the proper controls in place to handle that. -- Mark Thomas Internet Systems Architect ___ BAE SYSTEMS Information Technology 2525 Network Place Herndon, VA 20171 USA ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
RE: security diff between hidden fields and cookies
> I would like to get some opinions on what is safter, > hidden fields or cookies ? > For my particular program Im thinking that hidden fields might be safer because its a in house web based program > (postgressql dbase) and > * all files live in a protected folder that outside users should not be > able to get to > Im currently have auth levels stored in a hidden var and pass from page > to page... > a coworker said he thought cookies would be more secure... > Im going to do the research but thought it wouldnt hurt to ask > thanks > Lori A better way is to assign each user a session ID and pass it along as a cookie value or hidden form field. Keep the login info & auth levels in an isolated table along with your session ID. i.e. RowID RealName User Pass AuthSID 0 John Doe Jdoe dog 10 J7h62Gr841D2c9W33a74P8m9H6t1W 1 Jane Smith Jsmith cat 8 [Random String] 2 Ron ClarkRclark purple 5 [Random String] - Chris ___ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
