RE: Application passwords

From: Jason Coombs (jasonc@science.org)
Date: 07/26/02 

From: "Jason Coombs" <jasonc@science.org>
To: "Marcus James" <marcus01@post.com>, <security-basics@securityfocus.com>
Date: Thu, 25 Jul 2002 15:56:16 -1000

Aloha, Marcus.

I enjoyed reading your security scenario. Both you and your users have valid
points. You ask a question that needs an answer, if only to demonstrate that
there is no answer:

> How do I convince them that they need to implement password controls for
this
> application and not only network logon controls?

Malicious code that executes on the user's computer will have unrestricted
AUTOMATIC access to company sensitive confidential data. Any person who has
physical access to the computer will have AUTOMATIC access as well, if the
user has already logged-in.

The only difference another password makes is that either malicious code or
a third party with physical access to the computer has to capture the
credentials before they will have AUTOMATIC access to the data. Or, the
attacker can capture only the data the user accesses from the confidential
data storage.

Because you can't be 100% sure of preventing all malicious code within and
all unauthorized physical access to the computers in question, adding
another password improves security only marginally by increasing the
complexity of a successful attack.

It upsets your users because they want AUTOMATIC access to the confidential
information. Since their computer already knows who they are, it should just
give it to them. However, you must prevent AUTOMATIC access to confidential
data based only on a logged-in identity if you can. But, attempting to do so
in software isn't especially useful because it leaves the system vulnerable
to software attacks and a third party can still gain physical access to the
box to capture credentials.

I recommend that you find a compromise solution. Acknowledge that you won't
be able to prevent malicious software from accessing a copy of data the user
accesses. Further, decide not to worry about physical security to any
greater extent than you already have. Deploy a system that puts a stop to
all possibility of malicious code achieving unrestricted AUTOMATIC access to
the sensitive data: a light switch. Wire a simple switch at each user's
workstation that cuts off network access and train users to flip it when
they leave their computers.

Combine this with a prove-you're-human access restriction counter measure. A
good one is software on the server that spits out a randomly-generated
graphic image containing a passcode that the user must read and type into a
form field in order to begin a new session.

These two protections give you what you really want: proof the user is human
and proof they are sitting at their computer working at the time of the
request for access to the sensitive data. Another password doesn't give you
these assurances, it just makes remote attackers work harder. You can defend
your users against remote attackers without bothering the users. More
passwords don't prevent remote automated malicious code attacks but a light
switch and a one-time-use prove-you're-human passcode might. And it won't
inconvenience your users.

Sincerely,

Jason Coombs
jasonc@science.org

-----Original Message-----
From: Marcus James [mailto:marcus01@post.com]
Sent: Wednesday, July 24, 2002 6:32 AM
To: security-basics@securityfocus.com
Subject: Application passwords

Hi,

I'm in need of some creative ideas. We are rolling out an application to a
select number of users in an organisation (50-70 users). Those users would
be able to access sensitive and company confidential information such as
financial data as well as (personal) customer information. Their
functionality will be controlled via the use of roles. The application will
be accessed via a browser.

The problem is that they do not want to implement password controls for the
application, i.e. once the user is logged onto the W2K network they would
not need to log in to use the application. The reason they are doing this is
for ease-of-use and they do not want to bother with password ageing, account
lockout etc. for the application.

They believe that as long as the network logon controls (and processes) are
robust they do not need to implement application password controls. While
the network logon does have and enforce password controls, i.e. password
expiry, password history, length, lockout etc. the processes are a bit
dodgy.

While I understand the need for ease of use, and the impracticality of
maintaining and remembering many passwords I find this potentially a huge
security exposure.

How do I convince them that they need to implement password controls for
this application and not only network logon controls?

Alternatively what would need to be in place to ensure that application
password controls are not needed?

Perhaps someone can share some of their experiences with me.

Thanks... 

--
__________________________________________________________ Sign-up for your
own FREE Personalized E-mail at Mail.com http://www.mail.com/?sr=signup  Get
4 DVDs for $.49 cents! plus shipping & processing. Click to join.
http://oas-central.realmedia.com/RealMedia/ads/click_lx.ads/mail.com/columbi
ahouse/1112745096/x09/ExactAdv/ColumbiaHouse_IO473_7.19_8.19/blank.gif/63663
2633232383133383736634333430

Quantcast