RE: security diff between hidden fields and cookies

[Chris]

 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

Re: security diff between hidden fields and cookies

[Kevin Carothers]

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