Password on close (again)

[Frank L]

I have some accounting and tax receipting type applications, developed
for charitable and non profit groups, that are exhibiting strange
behaviour on a few of the 30 or 40 user machines.

When some users (about 3 or 4 it seems) close the frontend db the Access
database password prompt appears. Users can just Cancel the pw prompt
(or enter the correct password) and the db will then close.

On the MS Office forum I found a post that suggested this is due to
Compact on Close (which I indeed used on the frontend db); however the
post there said that the password prompt would probably only occur on
systems running Access 2000 but not on Access XP nor 2003.

I don't see most of the pcs that are running these apps (they download
the frontend and backend dbs from a web site and some may have the
problem and not report it) but on some recent onsite visits I've found
the problem on the following systems:

Windows 98 / Access 2000 - newly downloaded acctg & receipt apps both
Windows XP / Access 2002 - uses accounting system only
Windows XP Home 2002 SP1 / Access 2002 - uses accounting system only

The apps do not exhibit this behaviour on the development machine (Win
Me Access 2002/XP SP3) nor on several other machines of various OS and
Office vintages.

Things I've tried:
• Decompile / recompile (on the development machine). This seemed to
cure one machine (Windows XP Pro / Access 2002) but the three systems
above downloaded the latest recompiled application systems and still
asked for pw on close. On another system that exhibited the password on
close problem the recompiled app seemed to cure the problem but the user
had upgraded from Access 2002 to Access 2003 in the meantime.

• unsetting and resetting the password - not a cure.

The apps themselves are all similarly designed with the frontends saved
in Access 2000 format and the backends saved in Access 97 format.
(there is also an Access 97 frontend for A97 users - these don't exhibit
the problem which seems to support the tie-in with compress on close).
The password is set on the frontend and backend dbs (same pw). The apps
have been in production for just over a year but the password on close
situation didn't seem to surface until about 6 months ago (which may
have coincided with setting Compact on Close on the frontend ... I don't
have a record when this practice ensued).

This password on close phenomenon has me totally perplexed. Since I
don't have ready access to a machine that exhibits the problem I can't
even experiment to see if I can diagnose the problem. It's happening
enough that it's no longer a one-off glitch but it's incidence is still
low so it doesn't seem to be an inherent design thing I've done.

Any thoughts on this is most appreciated.

TIA

PS. I know the Access pw isn't the greatest security in the world (locks
just keep honest people out etc.) but these applications need at least a
minimal password challenge just to comply with ease of access guidelines.
--
F L
-

[David W. Fenton]

Frank L <Le***************@sympatico.ca> wrote in
news:YS*****************@news20.bellglobal.com:

On the MS Office forum I found a post that suggested this is due
to Compact on Close (which I indeed used on the frontend db)

Compact on close is a bad thing.

1. if there is unrecoverable corruption, you could lose data in the
compacted database, if there is any, with no way to cancel out of
it.

2. it's of no value on a properly designed front end, which doesn't
really benefit from being compacted at all.

And database passwords are worth about as much as a worm bucket of
spit, in any case.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

[Frank L]

David W. Fenton wrote:

Frank L <Le***************@sympatico.ca> wrote in
news:YS*****************@news20.bellglobal.com:

On the MS Office forum I found a post that suggested this is due
to Compact on Close (which I indeed used on the frontend db)

Compact on close is a bad thing.

1. if there is unrecoverable corruption, you could lose data in the
compacted database, if there is any, with no way to cancel out of
it.

2. it's of no value on a properly designed front end, which doesn't
really benefit from being compacted at all.

And database passwords are worth about as much as a worm bucket of
spit, in any case.

I may well drop the compact on close option for the frontends - these
are smallish dbs (under 2MB) that don't seem to bloat to more than 2.5MB
in any case. OTOH, there have been no failures in the last couple of
years of production, but if compact on close did corrupt the f/e, the
user would just download a fresh copy.

Still can't account for the variable behaviour of the password on close
issue. The mental aggravation of this problem may lead me to remove the
compact on close moreso than the technical merits (or lack) of compact
on close.

Password protection is necessary to comply with federal guidelines that
require access controls on systems that issue charitable receipts for
income tax purposes. The guidelines don't specify the strength of the
deterrent. So, it doesn't matter that Access's pw can be compromised,
just that there is a pw.
--
F L
-

[David W. Fenton]

Frank L <Le***************@sympatico.ca> wrote in
news:mD*******************@news20.bellglobal.com:

Password protection is necessary to comply with federal guidelines
that require access controls on systems that issue charitable
receipts for income tax purposes. The guidelines don't specify
the strength of the deterrent. So, it doesn't matter that
Access's pw can be compromised, just that there is a pw.

If you're happy with cosmetic fixes that could be cracked by anyone
after 5 minutes of Googling, I guess that's OK.

But I sure wouldn't want to face a review by the Feds under those
circumstances.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

[Frank L]

David W. Fenton wrote:

Frank L <Le***************@sympatico.ca> wrote in
news:mD*******************@news20.bellglobal.com:

Password protection is necessary to comply with federal guidelines
that require access controls on systems that issue charitable
receipts for income tax purposes. The guidelines don't specify
the strength of the deterrent. So, it doesn't matter that
Access's pw can be compromised, just that there is a pw.

If you're happy with cosmetic fixes that could be cracked by anyone
after 5 minutes of Googling, I guess that's OK.

But I sure wouldn't want to face a review by the Feds under those
circumstances.

My thinking up to now was that using the Access password was preferable
to trying to develop any security solution on my own. I was assuming
(maybe wrongly?) that it would be difficult to do and I couldn't one-up
Microsoft. And it would seem by doing so I take more of the
responsibility on myself (akin to modifying the car's seatbelts) rather
than using the product asis. But if there were something simple to
implement I would go for it, given all the password cracking products
and services out there for Office (not to mention Accpac, Simply Acctg
etc which some of my users also have)

What alternatives would you recommend?

I'd like to avoid the purchase of a 3rd party product since these
database apps were developed and are supported for free and it would be
difficult or at least unpopular to pass on the costs to the end users.

In my recent contacts with the Charities Directorate they have been
focused on broad adherence to controls and procedures (safeguarding of
blank receipt media, serialization of receipts, identification of
reissued duplicates, access to computer systems etc). I guess they have
enough groups not doing even the basics right that this is a success.
Not to say they won't someday soon delve into the arcane world of
password protection especially as part of a general compliance exception
audit. Maybe by then I'll have something better.
--
F L
-

[David W. Fenton]

Frank L <Le***************@sympatico.ca> wrote in
news:xi*******************@news20.bellglobal.com:

David W. Fenton wrote:

Frank L <Le***************@sympatico.ca> wrote in
news:mD*******************@news20.bellglobal.com:

Password protection is necessary to comply with federal
guidelines that require access controls on systems that issue
charitable receipts for income tax purposes. The guidelines
don't specify the strength of the deterrent. So, it doesn't
matter that Access's pw can be compromised, just that there is a
pw.

If you're happy with cosmetic fixes that could be cracked by
anyone after 5 minutes of Googling, I guess that's OK.

But I sure wouldn't want to face a review by the Feds under those
circumstances.

My thinking up to now was that using the Access password was
preferable to trying to develop any security solution on my own. I
was assuming (maybe wrongly?) that it would be difficult to do and
I couldn't one-up
Microsoft. . . .

You don't have to roll your own security. Just use the built-in Jet
user-level security. There would then be no password prompt for any
of the compact-on-close operations.
. . . And it would seem by doing so I take more of the
responsibility on myself (akin to modifying the car's seatbelts)
rather than using the product asis. But if there were something
simple to implement I would go for it, given all the password
cracking products and services out there for Office (not to
mention Accpac, Simply Acctg etc which some of my users also have)

What alternatives would you recommend?
Well, certainly, thought Jet user-level security can be cracked,
it's much harder than cracking the Access password, so that's what
I'd recommend.
I'd like to avoid the purchase of a 3rd party product since these
database apps were developed and are supported for free and it
would be difficult or at least unpopular to pass on the costs to
the end users.
I don't see how any 3rd-party product could protect your data.
In my recent contacts with the Charities Directorate they have
been focused on broad adherence to controls and procedures
(safeguarding of blank receipt media, serialization of receipts,
identification of reissued duplicates, access to computer systems
etc). I guess they have enough groups not doing even the basics
right that this is a success. Not to say they won't someday soon
delve into the arcane world of password protection especially as
part of a general compliance exception audit. Maybe by then I'll
have something better.

You have an alternative to the database password other than rolling
your own. And it's going to be more secure than anything you could
write on your own.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

[Br]

David W. Fenton wrote:
<>

Well, certainly, thought Jet user-level security can be cracked,
it's much harder than cracking the Access password, so that's what
I'd recommend.

Actually, it's easier (for me anyway:). I have a crack that resets the
default admin user's rights to the full database (haven't tried it on
A2002/3 yet). As it just patches the file with a small value it runs almost
instantly (though the file is likely left unstable so you'd need to import
all the objects to a clean db). To discover a database password you have to
decrypt it which can take a while (it's easier with older versions).

I've seen some strange DB passwords in my time that use weird characters. If
you set the password via code can you use characters that can't (or are
difficult) to type?

<>
--
regards,

Br@dley