Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
Encryption dll/activex/class
Message
De
09/04/2014 17:27:16
 
 
À
09/04/2014 17:21:38
Information générale
Forum:
Visual FoxPro
Catégorie:
Contrôles ActiveX en VFP
Versions des environnements
Visual FoxPro:
VFP 9 SP2
OS:
Windows 7
Network:
Windows 2008 Server
Database:
Visual FoxPro
Application:
Desktop
Divers
Thread ID:
01598213
Message ID:
01598396
Vues:
54
J'aime (1)
>>>>Hi Tore,
>>>>
>>>>I think you're right but it's hard to hear this
>>>>
>>>>Thanks
>>>
>>>Tore is not quite correct - DBF files can be protected but .... First, Cryptor is a discontinued product but does work under all versions of Windows including under 32 bit and 64 bit versions. The problem is that it is discontinued. There is another product found at the link below that will encrypt all or some of your files but allow your application to read-from and write-to them seamlessly from within your application. However, with any technology like this the security problem then moves up the line to needing to protect the password stored in the VFP application itself. If I can hack the VFP EXE and extract the password then I can access the encrypted database. Therefore I need to also protect the EXE file as best as I can. There are several options, all eventually crackable, but at least it's better than nothing. See this link for seamless file based encryption from within VFP or any other programming language that supports ActiveX / COM ... not cheap ... I guess it depends on how valuable your data is to you.
>>>
>>>http://www.netlib.com/file-encryption.asp
>>
>>Cyanide is quicker.
>
>A strange comment which I don't really understand. Within a few minutes he can encrypt his files, add in the DLL, make a call to the DLL, and have seamless on-the-fly encryption/decryption in his VFP app. What do you find hard about that for a developer with an existing VFP application using DBF files and needing an encryption solution? Do you think converting that application to SQL Server is a simpler solution? Just rhetorical questions.

I was referring to my earlier message that DBFs are not secure. You can do tricks to work around any problem, but trying to make a DBF secure is like converting a bicycle into a car. Why bother, when there are far better solutions. Especially now that DBFs will die sooner or later, I assert that using a "real" database server for storage is the best way to go.
Précédent
Suivant
Répondre
Fil
Voir

Click here to load this message in the networking platform