Prev: Open an external file from a formular
Next: Create Desktop Shortcuts
From: David W. Fenton on 24 Jan 2010 19:23
Banana <Banana(a)Republic.com> wrote in
news:4B5BBAFF.2000108(a)Republic.com:

> David W. Fenton wrote:
>> While the result of that may be that certain users don't see
>> certain things, it's still not what I'd call security, just a
>> useful form of obfuscation (i.e., security by obscurity).
>
> I'm having hard time imagining how could it be termed obfuscation
> because by using this technique there is no need to store any key
> or password and hide it.

You're hiding the data from them in the UI, not via the database
engine itself.

> By designing the application to depend on a
> specific domain & members of group (for AD - I've really not had
> the occasion to solve this for non-AD context), it cannot be used
> outside the domain, or by nonusers within the domain. It may not
> be 'security' but it certainly couldn't be obfuscation because
> there's nothing to obfuscate unless you want to consider the
> machine code as obfuscation needing to be decompiled.

I hadn't thought about that one.

> Now, this would be quite useless if the requirement was not to
> protect the code but also the data and the data was also stored in
> the ACCDE file. In such cases, the proper answer is to move out
> data into a server RDBMS, but in terms of protecting code & UI
> objects, this is an effective technique. In context of using a web
> database inside full Access, however, reduce the utility because
> of its reliance on macros which are still editable even in an
> ACCDE.

The only way to protect the code is to compile an ACCDE.

I don't think there's a way to protect UI objects (anybody can hit
the delete key, for instance, if they can get to the database
window).

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
From: Banana on 25 Jan 2010 14:24
David W. Fenton wrote:
> You're hiding the data from them in the UI, not via the database
> engine itself.

Given that even with ULS configured, one still can open the file and
read the data plaintext unless an extra step is taken to encrypt the
data, it seems to me to amount to basically the same thing as the
technique of using AD or NTFS security groups - the difference being the
source for checking the security & permissions.

At least in 2010 (2007?), setting a database password also encrypt the
file in one go and (for 2007 as well) API can be changed so a different
encryption can be used, unlike the utterly useless encryption available
in 2003 and earlier.

I don't deny that it is preferable that the security is done at lowest
level possible, but the fact is that when playing with a file, there's
only so much we can do about it and while ULS is useful in managing
whether a user should interact with an object, it does really nothing to
prevent unauthorized access to the data when the engine isn't involved.

> I don't think there's a way to protect UI objects (anybody can hit
> the delete key, for instance, if they can get to the database
> window).

I'm not aware of this. In ACCDE, at least, I can still delete standalone
macros, queries & tables but not forms, reports & modules.. Is this not
the case with MDE?
From: David W. Fenton on 25 Jan 2010 21:58
Banana <Banana(a)Republic.com> wrote in
news:4B5DEFFD.6080101(a)Republic.com:

> In ACCDE, at least, I can still delete standalone
> macros, queries & tables but not forms, reports & modules.. Is
> this not the case with MDE?

Beats me. I haven't used MDEs since c. 1999 (well, with one
exception -- one client's bookkeeper used to be very bad typing
through error messages; grrrr that she would ignore them and never
tell me about them, but she'd end up typing into the VBA module
where the error occured and then the app wouldn't compile, so that
computer has an MDE).

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
First  |  Prev  | 
Pages: 1 2 3
Prev: Open an external file from a formular
Next: Create Desktop Shortcuts