RE: Java w/Cookies

[Scott Diedrick <swd@utxvms.cc.utexas.edu>]

> Date:          Fri, 23 Feb 1996 14:29:44 -0600 (CST)
> From:          <javascript@obscure.org>
> Subject:       RE: Java w/Cookies
> To:            javascript@obscure.org

> Return-path: <owner-javascript@obscure.org>
> Received: from tol.travelogix.com by utxvms.cc.utexas.edu (PMDF V4.3-13 #8466)
>  id <01I1K0XZQV0WAPVI8O@utxvms.cc.utexas.edu>; Fri,
>  23 Feb 1996 14:29:41 -0600 (CST)
> Received: from obscure.org (204.192.122.2) by tol.travelogix.com with SMTP
>  (Apple Internet Mail Server 1.0); Fri, 23 Feb 1996 14:29:31 -0600
> Received: (from majordomo@localhost) by obscure.org (8.6.12/8.6.9)
>  id NAA06378 for javascript-outgoing; Fri, 23 Feb 1996 13:04:17 -0500
> Received: from scooby.nswses.navy.mil (scooby.nswses.navy.mil [137.24.10.19])
>  by obscure.org (8.6.12/8.6.9) with ESMTP id NAA06353 for
>  <javascript@obscure.org>; Fri, 23 Feb 1996 13:03:47 -0500
> Received: from 4G-GATEWAY.NSWSES.NAVY.MIL by scooby.nswses.navy.mil with SMTP
>  (1.37.109.16/16.2) id AA244498658; Fri, 23 Feb 1996 10:04:18 -0800
> Received: from ccMail by 4G-GATEWAY.NSWSES.NAVY.MIL (SMTPLINK V2.10.05)
>  id AA825101010; Fri, 23 Feb 96 10:08:29 PST
> Date: Fri, 23 Feb 1996 10:08:29 -0800 (PST)
> From: mike_grapevine@4G-GATEWAY.NSWSES.NAVY.MIL
> Subject: Re: Java w/Cookies
> Sender: owner-javascript@obscure.org
> To: javascript@obscure.org
> Reply-to: javascript@obscure.org
> Message-id: <9601238251.AA825101010@4G-GATEWAY.NSWSES.NAVY.MIL>
> Content-transfer-encoding: 7BIT
> Precedence: bulk
> 
>      
> >All over the world there are lots of servers, where you have to identyfy 
> >yourself with username and Password. Of course, Netscape (and other 
> >Browsers to) will remeber the last things you entered, but only during 
> >the current session. So far, so good.
> >
> >Having that in mind, I think it would be a goog thing to have a page with 
> >lots of links to password protected pages, where all the username and 
> >Passwords are stored as cookies on client side, once they have been 
> >entered. You know what I mean?
> 
>         I've been developing CGI applications that require an account and       
>         password to be propagated to the successive pages that make up the
>         CGI application. Initially, I started using hidden text fields to do
>         this, assigning the account and password values each to a hidden field.
>         The CGI program read these values on submission of a form, and stores   
>         them as hidden text fields in the resulting HTML code that makes up the 
>         following page. Just keep on doing this for all successive pages of a   
>         CGI application that generates dynamic pages.
> 
>         The problem with this approach of using hidden text fields is that the  
>         account and password values are stored as clear text in the HTML code. 
>         Someone can inadvertantly disclose their account and password by        
>         printing or displaying the HTML code that makes up one of these pages 
>         the CGI application in their browser. 
> 
>         One thing that I have done is using Netscape frames in addition         
>         to the hidden text fields in CGI applications. As far as I can find out,
>         there is no way to directly print or display the HTML code of a frame   
>         in a page being displayed in the current Netscape browser. 
> 
>         I know there has to be a better, more secure way than this to           
>         propage user authentication information in a CGI application. Has anyone
>         developed a better technique than this ? 
> 
> 
> --------------------------------------------------------------------
> This message came from the mailing list javascript. For help using the
> mailing list software, please send a message to 'majordomo@obscure.org'
> with the message body 'help'. To unsubscribe, send a message to
> 'majordomo@obscure.org' with the message body 'unsubscribe javascript'.
>
At our company we keep the user name and password in hidden text 
feilds also.  But first we encrypt them with a key on the server 
side.  This key changes every so often, say 30 minutes, and the 
server checks the current key and the last key.  This means that the 
users password is secure and that they or anyone else can't just 
reload and resumit a page a day later to messup you CGI.  Their key 
would have timed out long ago. 
                     Scott Diedrick
--------------------------------------------------------------------
This message came from the mailing list javascript. For help using the
mailing list software, please send a message to 'majordomo@obscure.org'
with the message body 'help'. To unsubscribe, send a message to
'majordomo@obscure.org' with the message body 'unsubscribe javascript'.