The original dB File can only be accessed by the username it is
opened under, ( a different one than the logon username for the OS ), so it
cannot be read until the application is shut down. But you did make me
realize that I should make the file exclusive to that user only, even if the
app isn't running in the event something prevents the encryption and delete
procedures from running. I can do this when the original file is first
created, as by then the username will have been set.
As it was explained in the worksheet I was given, they are really
only worried about users who have access to the application but under a
different logon name. That's why I set this up to run with each user having
their own file, even if plugged into the local network. You may remember an
app I mentioned writing for a guy a few years back where he had three shifts
working on the same computers. Well they've upgraded to Vista all around,
and so far the UAC seems to work pretty well provided the head man who had
full control privileges doesn't get lazy and allow any other users more
access control to root directories.
No, if they needed to worry about data theft to any great degree, I
wouldn't even touch it. I don't have any experience with high level
security issues. Oh yes, as to the problem...I was trying to get around the
trade-off between access speed and the vendor's method of file encryption,
witch is only important for a couple tables that access shell functions and
really don't even present any security risk at all. But as they handle
their security on a page basis for the entire single dB File, the only way I
could prevent the trade-off was by handling it myself pre and post actually
working with the File. Individual record encryption prevents anyone from
getting at the open file while away from your desk, and Exclusive access to
the tables provides protection from another application running elsewhere at
the same time a file is actually opened. So the only downside to this is
that should the app terminate without closing down first, there could still
be left a file behind that could possible be opened by another app, But I
don't think that's something I really need to worry about as long as they
encrypt those records that need higher security individually, within the
transactions. In fact, individual record encryption should be more than
enough, but they're requiring full file encryption. I imagine I'll have the
opportunity to speak to him some more about this, but he can't have it both
ways!
from Robert Meek dba "Tangentals Design"
e-mail: [EMAIL PROTECTED]
Freelance Windows Programming for XP and Vista
Also proud to be a Moderator of the "Delphi-List" at elists.org
"Reality cannot be explained...only enjoyed or endured as your current
perspective allows!"
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Rob Kennedy
Sent: Thursday, October 04, 2007 6:00 PM
To: Delphi-Talk Discussion List
Subject: Re: Creating new solutions
Robert Meek wrote:
> At the same time, my client, whom I don't believe ever used the word
> "security" in a sentence before his firm was computerized, was insistent
> that I use the cheapest database possible AND that it be "secure"!
Secure from what? The database has parameters, files, and desktop
shortcuts, and it needs NSA-grade encryption? What security risks is your
client hoping to protect against?
Someone else already pointed out that when you delete the source file
you're crippled if the program crashes. But your program could run
perfectly and still expose the data in an unencrypted manner. While your
program is running, the entire database file is sitting there on the disk
unencrypted. Any other program running as the user could read it. You'd be
in exactly the same situation if you had never encrypted the database at
all and just left it in the user's folder all the time.
So I'm still unclear on what the problem was, and on how what you did
solved it.
--
Rob
__________________________________________________
Delphi-Talk mailing list -> Delphi-Talk@elists.org
http://www.elists.org/mailman/listinfo/delphi-talk
__________________________________________________
Delphi-Talk mailing list -> Delphi-Talk@elists.org
http://www.elists.org/mailman/listinfo/delphi-talk
