in IE5:
tools/internet options/content/AutoComplete/prompt me to save passwords
Bert
> -----Original Message-----
> From: craig girard [mailto:[EMAIL PROTECTED]]
> Sent: 05 July 2000 21:33
> To: [EMAIL PROTECTED]
> Subject: RE: <CF_SECURE>
>
>
> I do not believe the MS autocomplete works on an input of
> type PASSWORD. I
> use autocomplete in IE and have never had it come up when the
> input type is
> PASSWORD.
>
> Craig
>
> -----Original Message-----
> From: David B. Brooks [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, July 05, 2000 3:30 PM
> To: [EMAIL PROTECTED]
> Subject: RE: <CF_SECURE>
>
>
> As per prompting for password before updating, the user might
> have MS auto
> complete (or some other form that I don't know of) on in
> their browser, thus
> defeating this purpose.
>
> Anyway to turn this feature off?
>
> -David
>
>
> -----Original Message-----
> From: Nat Papovich [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, July 05, 2000 2:20 PM
> To: '[EMAIL PROTECTED]'
> Subject: RE: <CF_SECURE>
>
>
> The trick is this - if someone is just staring at their
> ticker tape on their
> eTrade screen, waiting for ALLR to dip below 15, they could
> wait for a very
> long time. During these periods of inactivity, the hidden
> frame is still
> refreshing every 3 minutes, keeping the session active.
> Therefore, you can
> set the session timelimit to 3 mins or 5 mins or whatever and
> assured that
> you won't drop someone if they're just watching the screen or
> if they hav
> multiple browsers open and they want to keep their ETrade
> account logged in
> while they read the market reports elsewheres.
>
> And yes, if your users were IE guaranteed, iframe is good.
> Again, you need
> to clearly define your target audience, business needs, and user
> requirements. If you want super security, go ahead and use
> IP-based client
> identification, AOL users be damned.
>
> As for your #13 below about multiple password prompts - I
> think it's a good
> idea.
>
> NAT
>
> -----Original Message-----
> From: Steve Nelson [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, July 05, 2000 11:50 AM
> To: [EMAIL PROTECTED]
> Subject: Re: <CF_SECURE>
>
>
> Couldn't you just compare the #client.lastvisit# variable to
> #now()# and
> if it's greater than 3 minutes (or 20 minutes or 2 hours....whatever)
> then force them to login again. Even if the user walks away
> from their
> terminal if someone comes onto their machine after the
> timeout happened,
> it would require them to login regardless of where they clicked.
>
> What's the reason for the frame? Does it ensure that not even the
> screen that is currently displaying to the user disappears after a
> certain amount of time?
>
> If your users are IE users, you could use a hidden <iframe> tag. It
> would make development much easier.
>
> Let's add it to the list, I've got another one too.
>
> 12) Hidden <frame> or <iframe> containing a meta refresh
> checking to see
> if the user should be logged out. If so, automatically force a login,
> even without user intervention.
> 13) If a user is submitting personal data changes, require
> them to enter
> their password even if they are logged in. This will protect the user
> if they walked away from a terminal logged in. ALA Datek.com
>
> Steve
>
> Nat Papovich wrote:
> >
> > Ok here's an idea for max security, using frames. If you
> don't like it,
> > don't use it.
> >
> > Set up the entire app in 2 frames. One frame is "hidden" i.e. 1 or 0
> pixels
> > tall (or wide, I prefer tall). The other one is the
> mack-daddy do-it-all
> > frame. You have to keep this in mind throughout the rest of the
> application
> > because some JavaScripties will hose you if you forget
> you're in a frame
> > already.
> >
> > Now your hidden frame has a meta-refresh on it, set to oh,
> say, 3 minutes
> or
> > less. This hidden frame just queries ANY client variable.
> It just asks for
> > say, userid or URLToken or whatever. It's purpose is simply
> to guarantee
> > that a session stays active, and to allow deletion of the
> client records
> > after a certain timeframe has passed without a client var hit.
> >
> > You can query the CDATA/CGLOBAL tables for lasthit, and if
> it's less than
> > your hidden frame's refresh rate, you know the user is
> still there (or was
> > still there within the refresh rate time period). If it's
> older, you know
> > they're gone.
> >
> > Good yah?
> >
> > NATTY
> >
> > -----Original Message-----
> > From: Steve Nelson [mailto:[EMAIL PROTECTED]]
> > Sent: Wednesday, July 05, 2000 10:42 AM
> > To: [EMAIL PROTECTED]
> > Subject: Re: <CF_SECURE>
> >
> > Get more detailed. I wanna hear the yucky stuff that I'm missing.
> > Although focus on the CF side of things, not the backdoor
> OS side, there
> > are too many variations there.
> >
> > I think with my 4 things I've listed it'll cover 40% of
> applications.
> > Here are a couple more ideas i've heard and thought up that
> might jump
> > us up to 50% from 1-4:
> >
> > 5) use application.cfm to verify the user is going through
> index.cfm and
> > not dsp_whatever.cfm
> > 6) place users in groups, passing a list of allowed groups into some
> > module in concepts 1-4
> > 7) Use email address and password instead of username, password for
> > better identity checking, (users are less likely to post their email
> > address on a
> > 8) when logging in, run the query to verify who they are, then set a
> > client variable and after they are logged in only check for
> the client
> > variable. If you need to logout a user you can do so by
> deleting the
> > client variable from the database.
> > 9) If a user belongs to one or more groups store a client variable
> > called #client.user_groups# with this list. Then if you
> need to secure
> > a 'section' of a page, the check to see if the user has
> this variable
> > and has one of the groups that is allowed to view this section
> > 10) Don't require cookies, use the URLtoken, and allow the user to
> > decide at the login page whether they want the cookie set
> or not. Never
> > store anything other than the user's token in a cookie, all
> sensitive
> > information should be on the server in a client variable
> > 11) Maintain user focus by using the <cf_returnfuseaction>
> tag. This
> > will allow a user to view one page, login and be sent back
> to the page
> > they were viewing.
> >
> > I'm rambling a little, and I need to summarize the multi-user login
> > stuff from the porn discussion. I've got a better version of these
> > ideas down on paper, but I'm not done by any means.
> >
> > Give me more ideas.
> >
> > Steve
> >
> > Nat Papovich wrote:
> > >
> > > Is there a difference between
> > > >1. Securing every Fuseaction in one circuit applications
> > > and securing access to an entire circuit application?
> > >
> > > In implementation, yes. In concept, maybe. The security
> model would be
> > more
> > > global in aspect, not modularized to the FA.
> > >
> > > Hmmm...
> > >
> > > There are many more security issues to think about, but
> they're on a
> very
> > > different dimension than what you mentioned. I'm thinking
> of things like
> > > multiple logins, use of application.cfm, telnets,
> click-paths, yucky
> > stuff.
> > >
> > > Jah love,
> > > NAT
> > >
> > > -----Original Message-----
> > > From: Steve Nelson [mailto:[EMAIL PROTECTED]]
> > > Sent: Wednesday, July 05, 2000 9:35 AM
> > > To: Fusebox
> > > Subject: <CF_SECURE>
> > >
> > > Minor topic change... let's get off the porn and flaming
> issues and talk
> > > about security in general. It's an important topic that needs
> > > discussing.
> > >
> > > I'm writing all the ideas that everyone has been giving
> me down, and
> > > will publish them when I'm done. Here are the four main
> areas that I
> > > see necessary to secure...
> > >
> > > 1. Securing every Fuseaction in one circuit applications
> > > 2. Securing every Fuseaction in multiple circuit applications
> > > 3. Securing some Fuseactions in a circuit
> application, but not all
> > > 4. Securing certain areas of a single Fuseaction
> > >
> > > Does that sound about right to everyone? Am I missing
> anything? I want
> > > to try and create a drop-dead easy open-source security
> module that will
> > > work in 90% of all Fusebox applications.
> > >
> > > The best way I have found to make something work cross
> application is to
> > > focus on the concepts, not the implementations. So if you've got
> > > concepts about how to secure a Fusebox app let's hear them.
> > >
> > > Steve
> > >
> >
> --------------------------------------------------------------
> --------------
> > > --
> > > To Unsubscribe visit
> > >
> http://www.houseoffusion.com/index.cfm?sidebar=lists&body=list
> s/fusebox
> or
> > > send a message to [EMAIL PROTECTED] with
> 'unsubscribe'
> in
> > > the body.
> > >
> >
> --------------------------------------------------------------
> --------------
> > --
> > > To Unsubscribe visit
> >
> http://www.houseoffusion.com/index.cfm?sidebar=lists&body=list
> s/fusebox or
> > send a message to [EMAIL PROTECTED] with
> 'unsubscribe' in
> > the body.
> >
> --------------------------------------------------------------
> --------------
> > --
> > To Unsubscribe visit
> >
> http://www.houseoffusion.com/index.cfm?sidebar=lists&body=list
s/fusebox or
> send a message to [EMAIL PROTECTED] with 'unsubscribe' in
> the body.
>
----------------------------------------------------------------------------
--
> To Unsubscribe visit
http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/fusebox or
send a message to [EMAIL PROTECTED] with 'unsubscribe' in
the body.
----------------------------------------------------------------------------
--
To Unsubscribe visit
http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/fusebox or
send a message to [EMAIL PROTECTED] with 'unsubscribe' in
the body.
----------------------------------------------------------------------------
--
To Unsubscribe visit
http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/fusebox or
send a message to [EMAIL PROTECTED] with 'unsubscribe' in
the body.
----------------------------------------------------------------------------
--
To Unsubscribe visit
http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/fusebox or
send a message to [EMAIL PROTECTED] with 'unsubscribe' in
the body.
----------------------------------------------------------------------------
--
To Unsubscribe visit
http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/fusebox or
send a message to [EMAIL PROTECTED] with 'unsubscribe' in
the body.
------------------------------------------------------------------------------
To Unsubscribe visit
http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/fusebox or send a
message to [EMAIL PROTECTED] with 'unsubscribe' in the body.
