Security required - replace Access?

[Stav]

Hi there.

I'm working on an application that currently uses DAO to connect to an
Access 97 database. The database is created by and used exclusively by
the product to store search results and statistics during the
product's operation. The number of searches stored in one database
vary a lot (one user might only do 100 whilst another might do 1
million).

Once the search results have been stored, the product provides a
summary of the results using SELECT statements containing SUM
functions.

A new requirement for the product is that these results be encrypted
in such a way as that they cannot be viewed externally of the product
despite any reasonably determined attempt to do so.

I first considered using passwords and worgroup permissions but it
would appear that this protection is insufficient. I then considered
encrypting each of the fields in question, but these fields are also
the ones I want to carry out SUMs of, so I could no longer use them
and must implement my own function to decrypt each field and keep the
runnting total. Initial investigation seems to confirm this to be very
slow - are there any suggestions on how the performance of this could
be improved? The performance of the decryption algorithm itself is
reasonable, so I think my algorithm for performing the sum might be at
fault (simply MoveFirst, GetFieldValue, decrypt, add to total,
MoveNext) - how would one implement SUM normally?

Assuming I cannot get the performance up using encryption, I will have
to look at replacing Access. I want royalty-free distribution, so
initially looked at MSDE - will this inherently offer the security I
require? Are there any major downsides to implementing MSDE? Are there
other RDMBSs that I should also investigate?

Any advice you can offer me welcome. Thanks in advance,
Duncan

[Br]

Stav wrote:

Hi there.

I'm working on an application that currently uses DAO to connect to an
Access 97 database. The database is created by and used exclusively by
the product to store search results and statistics during the
product's operation. The number of searches stored in one database
vary a lot (one user might only do 100 whilst another might do 1
million).

Once the search results have been stored, the product provides a
summary of the results using SELECT statements containing SUM
functions.

A new requirement for the product is that these results be encrypted
in such a way as that they cannot be viewed externally of the product
despite any reasonably determined attempt to do so.

I first considered using passwords and worgroup permissions but it
would appear that this protection is insufficient. I then considered
encrypting each of the fields in question, but these fields are also
the ones I want to carry out SUMs of, so I could no longer use them
and must implement my own function to decrypt each field and keep the
runnting total. Initial investigation seems to confirm this to be very
slow - are there any suggestions on how the performance of this could
be improved? The performance of the decryption algorithm itself is
reasonable, so I think my algorithm for performing the sum might be at
fault (simply MoveFirst, GetFieldValue, decrypt, add to total,
MoveNext) - how would one implement SUM normally?

Assuming I cannot get the performance up using encryption, I will have
to look at replacing Access. I want royalty-free distribution, so
initially looked at MSDE - will this inherently offer the security I
require? Are there any major downsides to implementing MSDE? Are there
other RDMBSs that I should also investigate?

Any advice you can offer me welcome. Thanks in advance,
Duncan

Can't you use a backend database with a database password?

However, it is quite easy to break into any Access database regardless
of any security.

I think SQL Server allows you to create application security but haven't
used it myself.

Br@dley

[duncan.fawkes]

That's what I think I'll need to do, hence why I'm considering e.g.
MSDE. Encrypting on a field-by-field basis feels like jumping through
hoops to get Access to work for me, when replacing it is the proper
solution. However, replacing the backend DB is going to be quite a big
job so I want to make sure I've considered all options before doing so
- and then I have to think about choosing the right replacement (don't
want something too heavyweight).

Cheers.

Br@dley wrote:

Stav wrote:

Hi there.

I'm working on an application that currently uses DAO to connect to an Access 97 database. The database is created by and used exclusively by the product to store search results and statistics during the
product's operation. The number of searches stored in one database
vary a lot (one user might only do 100 whilst another might do 1
million).

Once the search results have been stored, the product provides a
summary of the results using SELECT statements containing SUM
functions.

A new requirement for the product is that these results be encrypted in such a way as that they cannot be viewed externally of the product despite any reasonably determined attempt to do so.

I first considered using passwords and worgroup permissions but it
would appear that this protection is insufficient. I then considered encrypting each of the fields in question, but these fields are also the ones I want to carry out SUMs of, so I could no longer use them
and must implement my own function to decrypt each field and keep the runnting total. Initial investigation seems to confirm this to be very slow - are there any suggestions on how the performance of this could be improved? The performance of the decryption algorithm itself is
reasonable, so I think my algorithm for performing the sum might be at fault (simply MoveFirst, GetFieldValue, decrypt, add to total,
MoveNext) - how would one implement SUM normally?

Assuming I cannot get the performance up using encryption, I will have to look at replacing Access. I want royalty-free distribution, so
initially looked at MSDE - will this inherently offer the security I require? Are there any major downsides to implementing MSDE? Are there other RDMBSs that I should also investigate?

Any advice you can offer me welcome. Thanks in advance,
Duncan
Can't you use a backend database with a database password?

However, it is quite easy to break into any Access database

regardless of any security.

I think SQL Server allows you to create application security but haven't used it myself.

Br@dley

[Tom van Stiphout]

On 19 Apr 2005 03:19:46 -0700, du***********@gmail.com (Stav) wrote:

I see a couple of options:
* Store the search data in such a way it is not easily humanly
readable but it is the same for same values.
Say a search for "firstname='Joe'"
is recorded as "2='Kpf'"
every time we search for Joe. You can sum over this data first, and
decrypt later:
Msgbox Decrypt(DSum("EncryptedField","SomeTable"))
(Note: I do NOT recommend DSum when speed is required - this is just
for illustration)

* Select sum(Decrypt(EncryptedField)) from SomeTable
Here you're having SQL do the heavy lifting of calling your public
Decrypt function in a module repeatedly. Of course this function is
optimized for speed. No error handler.

* Go to battle with the boss about the need for encryption on this
data.

-Tom.

Hi there.

I'm working on an application that currently uses DAO to connect to an
Access 97 database. The database is created by and used exclusively by
the product to store search results and statistics during the
product's operation. The number of searches stored in one database
vary a lot (one user might only do 100 whilst another might do 1
million).

Once the search results have been stored, the product provides a
summary of the results using SELECT statements containing SUM
functions.

A new requirement for the product is that these results be encrypted
in such a way as that they cannot be viewed externally of the product
despite any reasonably determined attempt to do so.

I first considered using passwords and worgroup permissions but it
would appear that this protection is insufficient. I then considered
encrypting each of the fields in question, but these fields are also
the ones I want to carry out SUMs of, so I could no longer use them
and must implement my own function to decrypt each field and keep the
runnting total. Initial investigation seems to confirm this to be very
slow - are there any suggestions on how the performance of this could
be improved? The performance of the decryption algorithm itself is
reasonable, so I think my algorithm for performing the sum might be at
fault (simply MoveFirst, GetFieldValue, decrypt, add to total,
MoveNext) - how would one implement SUM normally?

Assuming I cannot get the performance up using encryption, I will have
to look at replacing Access. I want royalty-free distribution, so
initially looked at MSDE - will this inherently offer the security I
require? Are there any major downsides to implementing MSDE? Are there
other RDMBSs that I should also investigate?

Any advice you can offer me welcome. Thanks in advance,
Duncan

[David Schofield]

On Tue, 19 Apr 2005 10:55:02 GMT, "Br@dley" <n0****@4u.com> wrote:

<big snip>

However, it is quite easy to break into any Access database regardless
of any security.

Rubbish

David

[Steve Jorgensen]

On 19 Apr 2005 10:06:01 -0500, d.***************@blueyonder.co.uk (David
Schofield) wrote:

On Tue, 19 Apr 2005 10:55:02 GMT, "Br@dley" <n0****@4u.com> wrote:

<big snip>

However, it is quite easy to break into any Access database regardless
of any security.

Rubbish

No - it's not rubbish. Access was not designed for high security, and it
doesn't have high security. Fortunately, most of us only need the kind of
security that keeps honest people honest.

[Steve Jorgensen]

Do you really mean "cannot be viewed externally of the product", or do you
mean "cannot be viewed any better outside the product than inside"? In other
words, is it that you want to limit what kinds of searches can be done by
whom, or is it that you want to prevent automated extract of the same search
results that could be obtained using the application UI.

The solution will be very different depending on the answer to the above.

On 19 Apr 2005 03:19:46 -0700, du***********@gmail.com (Stav) wrote:

Hi there.

I'm working on an application that currently uses DAO to connect to an
Access 97 database. The database is created by and used exclusively by
the product to store search results and statistics during the
product's operation. The number of searches stored in one database
vary a lot (one user might only do 100 whilst another might do 1
million).

Once the search results have been stored, the product provides a
summary of the results using SELECT statements containing SUM
functions.

A new requirement for the product is that these results be encrypted
in such a way as that they cannot be viewed externally of the product
despite any reasonably determined attempt to do so.

I first considered using passwords and worgroup permissions but it
would appear that this protection is insufficient. I then considered
encrypting each of the fields in question, but these fields are also
the ones I want to carry out SUMs of, so I could no longer use them
and must implement my own function to decrypt each field and keep the
runnting total. Initial investigation seems to confirm this to be very
slow - are there any suggestions on how the performance of this could
be improved? The performance of the decryption algorithm itself is
reasonable, so I think my algorithm for performing the sum might be at
fault (simply MoveFirst, GetFieldValue, decrypt, add to total,
MoveNext) - how would one implement SUM normally?

Assuming I cannot get the performance up using encryption, I will have
to look at replacing Access. I want royalty-free distribution, so
initially looked at MSDE - will this inherently offer the security I
require? Are there any major downsides to implementing MSDE? Are there
other RDMBSs that I should also investigate?

Any advice you can offer me welcome. Thanks in advance,
Duncan

[Lyle Fairfield]

David Schofield wrote:

On Tue, 19 Apr 2005 10:55:02 GMT, "Br@dley" <n0****@4u.com> wrote:

<big snip>

However, it is quite easy to break into any Access database regardless
of any security.

Rubbish

David

Why do you say this, David? I have felt for a very long time that any
application/file, whatever, is secure only in inverse proportion to the
worth of cracking it. Condie's chastity belt may be more secure than Jlo's.

That is, if it's worth my while, I or someone else will crack it.

In a current application I am using the crypt api functions from
advapi32 dll compounded by two false security trails interwoven into my
code which resides in an mde. I do hope that this scheme will defeat
someone who is playing around over morning coffee, but I'm not
confident it will prevent a determined and skillful hacker from breaking in.

[David Schofield]

On Tue, 19 Apr 2005 08:21:58 -0700, Steve Jorgensen
<no****@nospam.nospam> wrote:

On 19 Apr 2005 10:06:01 -0500, d.***************@blueyonder.co.uk (David
Schofield) wrote:

On Tue, 19 Apr 2005 10:55:02 GMT, "Br@dley" <n0****@4u.com> wrote:

<big snip>

However, it is quite easy to break into any Access database regardless
of any security.

Rubbish

No - it's not rubbish. Access was not designed for high security, and it
doesn't have high security. Fortunately, most of us only need the kind of
security that keeps honest people honest.

If done properly, it is rubbish that it is EASY, else PM wouldn't have
made a living at it. You try it.
David

[David Schofield]

On Tue, 19 Apr 2005 11:48:15 -0400, Lyle Fairfield <ly******@yahoo.ca>
wrote:

David Schofield wrote:

On Tue, 19 Apr 2005 10:55:02 GMT, "Br@dley" <n0****@4u.com> wrote:

<big snip>

However, it is quite easy to break into any Access database regardless
of any security.
Rubbish

David

Why do you say this, David? I have felt for a very long time that any
application/file, whatever, is secure only in inverse proportion to the
worth of cracking it. Condie's chastity belt may be more secure than Jlo's.

That is, if it's worth my while, I or someone else will crack it.

I agree with this!
In a current application I am using the crypt api functions from
advapi32 dll compounded by two false security trails interwoven into my
code which resides in an mde. I do hope that this scheme will defeat
someone who is playing around over morning coffee, but I'm not
confident it will prevent a determined and skillful hacker from breaking in.

Hi
see my reply to Steve. If an access db is secure properly it is
quite/very hard to bypass it. Only an idiot would say it is EASY.
David

[Larry Linson]

"David Schofield" wrote

If done properly, it is rubbish that it is
EASY, else PM wouldn't have made
a living at it. You try it.

David, Sergei Gavrilov had (and I assume still has) a free package on his
site that would retrieve all the necessary information to get into an Access
97 database, even if you did not have the workgroup file. I think he has it
there just to demonstrate what Steve just said. With that package, it IS
easy.

Access security has not been significantly changed since Access 97.

There are other third-party "password retrieval" packages around for later
versions... the going rate for a very capable one that will break 'user and
group' level security used to be US$140. If you Google, you might find
someone has said, "If your data is worth more to you than $140, use
something other than Access security to protect it."

Encrypting in Access is a separate issue, in any case. You do not specify
the keys, and anyone opening the database in Access can see the unencrypted
data. It is a feature just to keep someone with a disk zapper from going
around reading the information.

Larry Linson
Microsoft Access MVP

[Larry Linson]

"David Schofield" wrote

see my reply to Steve. If an access db
is secure properly it is quite/very hard
to bypass it. Only an idiot would say
it is EASY.

It doesn't require an idiot to be wrong; only someone who doesn't really
know what they are talking about. Steve Jorgensen is definitely not an
"idiot"; he does know what he is talking about.

I presume you are not, either.

However, a quick visit to Gavrilov's site, and trying his package on a
well-secured Access 97 database may convince you that you are wrong on this
issue.

Larry Linson

[Br]

Larry Linson wrote:

"David Schofield" wrote

If done properly, it is rubbish that it is
EASY, else PM wouldn't have made
a living at it. You try it.

David, Sergei Gavrilov had (and I assume still has) a free package on
his site that would retrieve all the necessary information to get
into an Access 97 database, even if you did not have the workgroup
file. I think he has it there just to demonstrate what Steve just
said. With that package, it IS easy.
There are also tools that basically give the default Admin user full
permissions again, hence no workgroup info is needed.
Access security has not been significantly changed since Access 97.

There are other third-party "password retrieval" packages around for
later versions... the going rate for a very capable one that will
break 'user and group' level security used to be US$140. If you
Google, you might find someone has said, "If your data is worth more
to you than $140, use something other than Access security to protect
it."

You can get many tools free (or illegally find serial codes for them).
You can buy tools to break any MSOffice product.

<>

Br@dley

[Br]

David Schofield wrote:

On Tue, 19 Apr 2005 10:55:02 GMT, "Br@dley" <n0****@4u.com> wrote:

<big snip>

However, it is quite easy to break into any Access database
regardless of any security.

Rubbish

I've got tools to break pretty much any Access database. You can easily
find them on the net.

Database passwords - easy
Workgroup security - easy
Encrypted database - takes a while longer but possible

Br@dley

[Br]

David Schofield wrote:

On Tue, 19 Apr 2005 08:21:58 -0700, Steve Jorgensen
<no****@nospam.nospam> wrote:

On 19 Apr 2005 10:06:01 -0500, d.***************@blueyonder.co.uk
(David Schofield) wrote:

On Tue, 19 Apr 2005 10:55:02 GMT, "Br@dley" <n0****@4u.com> wrote:

<big snip>

However, it is quite easy to break into any Access database
regardless of any security.
Rubbish

No - it's not rubbish. Access was not designed for high security,
and it doesn't have high security. Fortunately, most of us only
need the kind of security that keeps honest people honest.

If done properly, it is rubbish that it is EASY, else PM wouldn't have
made a living at it. You try it.
David

I can easily break an workgroup secured database in a matter of seconds
even without the workgroup file.

I'm afraid it is very easy.

Br@dley

[Br]

David Schofield wrote:

On Tue, 19 Apr 2005 11:48:15 -0400, Lyle Fairfield <ly******@yahoo.ca>
wrote:

David Schofield wrote:

On Tue, 19 Apr 2005 10:55:02 GMT, "Br@dley" <n0****@4u.com> wrote:

<big snip>

However, it is quite easy to break into any Access database
regardless of any security.

Rubbish

David
Why do you say this, David? I have felt for a very long time that any
application/file, whatever, is secure only in inverse proportion to
the worth of cracking it. Condie's chastity belt may be more secure
than Jlo's.

That is, if it's worth my while, I or someone else will crack it.

I agree with this!

In a current application I am using the crypt api functions from
advapi32 dll compounded by two false security trails interwoven into
my code which resides in an mde. I do hope that this scheme will
defeat someone who is playing around over morning coffee, but I'm
not
confident it will prevent a determined and skillful hacker from
breaking in.

see my reply to Steve. If an access db is secure properly it is
quite/very hard to bypass it. Only an idiot would say it is EASY.
David

David, I'm afraid you are wrong (and kinda rude too). I've been
developing in Access for over 10 years and know how to properly secure
an app.

Last year I had a client (the state's police in fact) who had a system
that was fully secured but they'd lost the workgroup file. It honestly
took me a matter of second to run some software and press a single
button to get into it.

If you are still not convinced I'm more than happy to demonstrate :)

Br@dley

[Bob Alston]

Br@dley wrote:

Larry Linson wrote:

"David Schofield" wrote

If done properly, it is rubbish that it is
EASY, else PM wouldn't have made
a living at it. You try it.

David, Sergei Gavrilov had (and I assume still has) a free package on
his site that would retrieve all the necessary information to get
into an Access 97 database, even if you did not have the workgroup
file. I think he has it there just to demonstrate what Steve just
said. With that package, it IS easy.

There are also tools that basically give the default Admin user full
permissions again, hence no workgroup info is needed.

Access security has not been significantly changed since Access 97.

There are other third-party "password retrieval" packages around for
later versions... the going rate for a very capable one that will
break 'user and group' level security used to be US$140. If you
Google, you might find someone has said, "If your data is worth more
to you than $140, use something other than Access security to protect
it."

You can get many tools free (or illegally find serial codes for them).
You can buy tools to break any MSOffice product.

<>

Br@dley

Yo Bradley, how about a link to one of the free tools to crack MS Access
2003 database with workgroup security where the workgroup security file
is not available? Only one I have found is the $140 or so one or
Gavrilov's service.

Bob

[Br]

Bob Alston wrote:

Br@dley wrote: <>

You can get many tools free (or illegally find serial codes for
them). You can buy tools to break any MSOffice product.

Yo Bradley, how about a link to one of the free tools to crack MS
Access 2003 database with workgroup security where the workgroup
security file is not available? Only one I have found is the $140 or
so one or Gavrilov's service.

While on one hand I don't like disseminating such information I know how
useful it was for me to be able to break a database when a client has
asked me to.

You can find the crack at http://mscracks.com/get.php?id=147178
(18Kb). Just click the download button.

Note: Watch for popups/spyware etc from this site. If you have WinXPSP2
you should be fine. The crack is virus free (scanned by Norton
Antivirus).

It should crack any non-encrypted, workgroup secured MDB without needing
the MDW. Basically all it does it give the default admin user full
permissions again. It works for Access 95 to 2002. I haven't tried it
with 2003 format databases yet (it's usually old databases people need
to get into because they've lost the MDW or something).

Obviously, backup your database first. Once cracked you should import
the objects from the cracked database to a new one as the database is
not going to be in a very fit state:)

Other commercially available tools I've used:

Access Password Recovery (one of the better ones)
Remove Access Security
Easy Pass
Advanced VBA Password Recovery Pro (for recovering password protected
VBA modules)

Note: Obviously I don't guarantee anything, I'm just sharing my
experiences.

Moral of this story: Give clients an MDE and if security of the data is
really important use SQL Server :)

Br@dley

[duncan.fawkes]

I mean that the data that is stored within the database should not be
available in a useful form outside of the product. So either it needs
to be encrypted to make it unusable outside of the product or it access
to it needs to be prevented. The idea is that a customer will view
statistics on what is contained within that database, but must pay a
fee per record to get the actual record data - and only once the
application has processed that payment will it export the data
contained within the database to a form the user can make use of
(either to a text file or to another database via ODBC).

Hope that clarifies things!

In response to Tom van Stiphout, unfortunately I cannot use the same
encrypted value for the same values as these values can be booleans, so
it would be obvious which was true and which was false unless a
different key was used to encrypt each record.

[David Schofield]

On Tue, 19 Apr 2005 23:45:11 GMT, "Br@dley" <n0****@4u.com> wrote:

David Schofield wrote:

On Tue, 19 Apr 2005 11:48:15 -0400, Lyle Fairfield <ly******@yahoo.ca>
wrote:

David Schofield wrote:
On Tue, 19 Apr 2005 10:55:02 GMT, "Br@dley" <n0****@4u.com> wrote:

<big snip>

> However, it is quite easy to break into any Access database
> regardless of any security.

Rubbish

David

Why do you say this, David? I have felt for a very long time that any
application/file, whatever, is secure only in inverse proportion to
the worth of cracking it. Condie's chastity belt may be more secure
than Jlo's.

That is, if it's worth my while, I or someone else will crack it. I agree with this!

In a current application I am using the crypt api functions from
advapi32 dll compounded by two false security trails interwoven into
my code which resides in an mde. I do hope that this scheme will
defeat someone who is playing around over morning coffee, but I'm
not
confident it will prevent a determined and skillful hacker from
breaking in.

see my reply to Steve. If an access db is secure properly it is
quite/very hard to bypass it. Only an idiot would say it is EASY.
David

David, I'm afraid you are wrong (and kinda rude too). I've been
developing in Access for over 10 years and know how to properly secure
an app.

Some others in the group are often ruder!
Last year I had a client (the state's police in fact) who had a system
that was fully secured but they'd lost the workgroup file. It honestly
took me a matter of second to run some software and press a single
button to get into it.

If you are still not convinced I'm more than happy to demonstrate :)

Br@dley

Hi
Ok, I'm the idiot, many apologies.

In my defence, the remark was only about how easy it was. I'm sure you
and others here can do it. My understanding was passwords useless,
group security harder (evidently now all public), encryption requires
trial and error.
David

[Steve Jorgensen]

On 20 Apr 2005 01:32:43 -0700, "du***********@gmail.com"
<du***********@gmail.com> wrote:

I mean that the data that is stored within the database should not be
available in a useful form outside of the product. So either it needs
to be encrypted to make it unusable outside of the product or it access
to it needs to be prevented. The idea is that a customer will view
statistics on what is contained within that database, but must pay a
fee per record to get the actual record data - and only once the
application has processed that payment will it export the data
contained within the database to a form the user can make use of
(either to a text file or to another database via ODBC).

Hope that clarifies things!

In response to Tom van Stiphout, unfortunately I cannot use the same
encrypted value for the same values as these values can be booleans, so
it would be obvious which was true and which was false unless a
different key was used to encrypt each record.

Yes, that clarifies things. Your problem is the hardest of the hard.

Encryption might help, but it is fundamentally difficult to make data
available for viewing on a computer and not possible to extract using that
same computer. I could install a copy of Vermont High Test ($250), and write
a script to run the program, read text off the screens, and write it to a
file. Granted, not a lot of people would know how to do that, but it can be
done. To make that harder, you'd have to do buffered screen output, so the
text is not available via the Windows API. Still, if someone wanted it bad
enough, they could use more automated batches to OCR the screen shot files.

Given the fundamental difficulty of this, someone needs to make a business
decision of just how secure the data needs to be first (knowing that 100%
can't happen), then come up with a plan based on those specifics.

[duncan.fawkes]

Thanks for the reply Steve.

Maybe I need to clarify a little further. It's not quite as complicated
as that. The data within the database is not available for them to view
within the application at all. They can see summary information that
tells them how many records match categories they've selected and hence
how much they have to pay, but they don't see the data at all.
Therefore encrypting would prevent them gaining access to this data
just by opening the Access database.

However, as I mentioned, that leads to the complication in that the
summary functions then need to include the decryption functions, rather
than using the straightforward SUM function as we do now, which means
we'll take a performance hit (unless we can massively optimise a custom
sum function).

So the options as I see them are to either encrypt the appropriate
fields in our current Access DB and take the performance hit, or to
move over to something like MSDE to prevent them getting into the DB in
the first place.

[Rick Brandt]

du***********@gmail.com wrote:

Thanks for the reply Steve.

Maybe I need to clarify a little further. It's not quite as
complicated as that. The data within the database is not available
for them to view within the application at all. They can see summary
information that tells them how many records match categories they've
selected and hence how much they have to pay, but they don't see the
data at all. Therefore encrypting would prevent them gaining access
to this data just by opening the Access database.

However, as I mentioned, that leads to the complication in that the
summary functions then need to include the decryption functions,
rather than using the straightforward SUM function as we do now,
which means we'll take a performance hit (unless we can massively
optimise a custom sum function).

So the options as I see them are to either encrypt the appropriate
fields in our current Access DB and take the performance hit, or to
move over to something like MSDE to prevent them getting into the DB
in the first place.

If you are summing I assume the data is just numbers. Couldn't you just encrypt
the names of the tables and fields making the numerical data useless without the
decrypted names? I mean what good is a column of numbers if you don't know what
they are?
--
I don't check the Email account attached
to this message. Send instead to...
RBrandt at Hunter dot com

[Steve Jorgensen]

On 21 Apr 2005 01:31:39 -0700, "du***********@gmail.com"
<du***********@gmail.com> wrote:

Thanks for the reply Steve.

Maybe I need to clarify a little further. It's not quite as complicated
as that. The data within the database is not available for them to view
within the application at all. They can see summary information that
tells them how many records match categories they've selected and hence
how much they have to pay, but they don't see the data at all.
Therefore encrypting would prevent them gaining access to this data
just by opening the Access database.

However, as I mentioned, that leads to the complication in that the
summary functions then need to include the decryption functions, rather
than using the straightforward SUM function as we do now, which means
we'll take a performance hit (unless we can massively optimise a custom
sum function).

So the options as I see them are to either encrypt the appropriate
fields in our current Access DB and take the performance hit, or to
move over to something like MSDE to prevent them getting into the DB in
the first place.

Moving them to a SQL Server would work great if you will be hosting the server
on a system you control. If the server will be located at the customer site,
that won't help.

[Steve Jorgensen]

On 20 Apr 2005 01:32:43 -0700, "du***********@gmail.com"
<du***********@gmail.com> wrote:

I mean that the data that is stored within the database should not be
available in a useful form outside of the product. So either it needs
to be encrypted to make it unusable outside of the product or it access
to it needs to be prevented. The idea is that a customer will view
statistics on what is contained within that database, but must pay a
fee per record to get the actual record data - and only once the
application has processed that payment will it export the data
contained within the database to a form the user can make use of
(either to a text file or to another database via ODBC).

Hope that clarifies things!

In response to Tom van Stiphout, unfortunately I cannot use the same
encrypted value for the same values as these values can be booleans, so
it would be obvious which was true and which was false unless a
different key was used to encrypt each record.

Regarding the encryption of booleans - you would not usually encrypt one
field, you would encrypt an entire entity. If you did encrypt a boolean, you
would use a technique called chaffing which is to include the bit as one part
of a larger block of random data, and encrypt the whole block.

[Larry Linson]

Using Access' encryption will make it difficult to use a disk zapper to read
the Fields in the Database, but if they copy the database and open it with
another copy of Access, the data will be readable. I don't know for certain,
but suspect it would also be readable if someone used VBA/DAO or VBA/ADO to
read the database from another application that supports VBA (like MS
Excel).

Larry Linson
Microsoft Access MVP

<du***********@gmail.com> wrote in message
news:11**********************@g14g2000cwa.googlegr oups.com...

Thanks for the reply Steve.

Maybe I need to clarify a little further. It's not quite as complicated
as that. The data within the database is not available for them to view
within the application at all. They can see summary information that
tells them how many records match categories they've selected and hence
how much they have to pay, but they don't see the data at all.
Therefore encrypting would prevent them gaining access to this data
just by opening the Access database.

However, as I mentioned, that leads to the complication in that the
summary functions then need to include the decryption functions, rather
than using the straightforward SUM function as we do now, which means
we'll take a performance hit (unless we can massively optimise a custom
sum function).

So the options as I see them are to either encrypt the appropriate
fields in our current Access DB and take the performance hit, or to
move over to something like MSDE to prevent them getting into the DB in
the first place.

[halain geojensen via AccessMonster.com]

Br@dley

I have a file that some guy has left. It has a reference to a module, owner
unknown. An .mdw file cannot be found.

You asked if a demonstration was needed. What would I do to get the text of
the vba module that is protected.

I need to upgrade this file to XP, perhaps I'll reset the security when it
is done.

Halain