I hadnt thought of that.  That would really work perfectly.  Thanks.
Jerry

Jon Lloyd Duerdoth wrote:
> Jerry,
>
> You could use the file description field to store some sort of encrypted
> string.
>
> Jon
>
> Jerry Blumenthal wrote:
>> Jerry Hayes wrote:
>>> http://bdn.borland.com/article/0,1410,26040,00.html
>>>
>>> But I'm not sure about the "extra field" part -- why use that instead
>>> of the password for the table?  What keeps the user from copying the
>>> file and then looking at other data besides the MAC field?
>>>
>>>
>>
>>
>> The file is password protected.  It can only be opened with the
>> password, which is embedded in a program that will show only certain
>> fields in the records.  Effectively, the extra field is hidden.
>>
>> If the user copies the file, he still cant look at other data without
>> that program.
>>
>> But even if he did, suppose the serial# is ABC123.  But when encrypted
>> and stored it comes out to 123456qwert09976.  He is not going to be
>> able to move that file to another computer and know how to send a
>> decrypted serial# to match the one on the new computer.
>>
>> I would prefer to put the extra field into the file header, but that's
>> a lot of trouble, and I dont know how; Tim would probably yell at me.
>> Besides, the extra field approach should work. I'm not looking for
>> government level security, just to prevent an employee from messing
>> around when he has no right to do so.
>>
>> Jerry

That's why I wrote in a back door.  The file will always open if you
enter a password that I can produce on my machine by entering a key that
only I know, and that is used to encrypt the DATE.  That way, it always
changes, and will be of no use after a day goes by.  The user simply has
to call me, I will give him the back door password to use, and it will
work so that a new password file can be implemented.

Jerry



Norman W. Clark [Clark-Tech Inc.] wrote:
> Jerry:
> You've touched on one of key shortcomings of the modern PC ... stuff fails!.  If
> you tie your data to the MAC address of one machine (and several of the methods
> cited are not foolproof - see my experience below) and if the user has to change
> out his Ethernet adapter, then how do you propose the user will be able to
> access his own data?  This hardware identity issue is a constant struggle in
> software licensing.
>
> Another approach you might consider would be to encode the data and have the
> encryption/decryption provided by a small service program that runs on the
> "intended" user's machine.  The service program could communicate via messaging
> with your application and provide the real-time encryption/decryption.  If
> another user attempted to view the data from another machine then the data is
> meaningless.  The "thief/casual user" would have to obtain all three
> components - the service program, your application and the data.  This approach
> does not depend on hardware and is portable to different environments.
>
> On the issue of MAC addresses, I have had some interesting experiences with all
> the methods cited in this thread.  One thing I would like to suggest to everyone
> who relies on any of the NetBIOS methods, is to test your application using the
> following approach:
> 1.    - Cold boot the target machine and immediately run your application -
> hopefully you will obtain the correct results.
> 2.    - Perform a "Log Out"/"Log In" without a cold boot in between then run
> your application and check your results.  I have experienced different NetBIOS
> results being received in this situation.  It can depend on the machine's BIOS,
> network adapter, protocols and even the protocols running on a remote server
> where the station might map a network drive.
>
> In short - be careful when using MAC addresses and ensure that you provide
> fall-back methods - you are likely to need them.
>