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=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.
------------------------------------------------------------------------------
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.
