Securing data
in [Help]
|
Prev: Linking an Excel file in Access with mixed data types in columns and #Num!
Next: Access 2010 with Sharepoint 2010
From: Salad on 5 Nov 2009 21:03 David W. Fenton wrote: > There is no encryption built into Access. > I thought there is in A2007. I don't believe you can encrypt specific tables or fields; it's all or nothing.
From: Finn Stampe Mikkelsen on 5 Nov 2009 21:38 "David W. Fenton" <XXXusenet(a)dfenton.com.invalid> skrev i meddelelsen news:Xns9CBAD16A2770Ef99a49ed1d0c49c5bbb2(a)74.209.136.90... > "Finn Stampe Mikkelsen" <stampe(a)city.dk> wrote in >> >> To specify the situation...: >> >> I have a database app, that presents pre-excisting data to a user. >> This data is supplied with the app and is not ment for the user to >> edit. Alongside this data, there is another database containing >> the user own additions to the data. > > Are these different data tables? What's the purpose of this data? > Does it like to the users' data? The app has not yet been programmed and is planned to be written in C# when done. The data can be in different tables or in seperate databases. Makes no difference to the application in the end.. The purpose of the data is as basis for a lookup. See it as a phonebook. It is not actually a phonebook, but similar. The data the user could add, could either be additional data to the records in the supplied data or complete records to enhance the data that can be accessed. Either way, the initial data needs to be compiled an that takes a lot of time so i would not like others to just be able to use that data raw with other apps. I really can't se how this in anyway could be illegal.. > >> What i wanted to encrypt was the data supplied with the app, to >> prevent someone from using this data to create there own app, with >> similar functionallity... > > Oh, boo hoo. What makes you think your precious data is so fabulous > that somebody would want to "steal" it? What kind of attitude is that. If you had a collection of data you had assembled, would you not like to protect it. Anyway, since the application would potentially be used by many, it would be subject to hacking. I really don't think i need to justify this to you or any other. > > Or that somebody who knows what they are doing can't just look at > your app and recreate the data and the functionality just by > understanding what your app does? > >> Real life example.. Picture a digital phone directory, with the >> option to add comments in the seperate database to every directory >> entry. The data i want to encrypt is the actual directory supplied >> with the program. i could'nt really care less about the data >> created by the user.. > > Data cannot be copyrighted, so you don't have copyright on the data. > That's why so many reference databases are locked behind pay > firewalls, because once it's out, it's legal for anyone to use it. �'m quite sure that you are correct as far as the use is restricted to the app to which it is supplied. I don't think i can rip just any data supplied with any software and use it for my own purpose and i am sure, that if i used that data to create a clone app with similar functions and thereby try to steal the market of the company that released the first app, that would not be legal.. > >> Wether the data is in front-end or back end i have no idea of what >> you talk about. Those concepts, datawise, are unfamiliar to me... > > Then you must be a novice Access programmer. No properly designed > Access app puts the data tables and all the forms/reports/etc. into > a single file. Instead, the user interface objects are in the > front-end file and the data tables in a separate file, which the > front end links to. I never, as far as i know, stated to have any experience with Access programming what so ever. In fact i asked here, cause i believed that i could get some help for that very same reason. You seem to have understood, that the app i'm intending to write, will be written in Access itself. This is not the case. It will be a DOT.NET C# app, standalone but using accdb files... The reason for that is besides the point. I could use SQLExpress or SQL Server, but the choice has been made to make it with an accdb database. > > >> Besides that, this debate is off-topic in relation to the original >> posting, concerning built-in ways to secure data in an accdb file. >> It seems not to be a feature available... > > There is no encryption built into Access. > > But if you need encryption, I don't think you should be using an > ACCDB to store your data. That may very well be true. But SQL Server is not an option and i opted to not use SQLExpress for reasons not important to this thread... > > -- > David W. Fenton http://www.dfenton.com/ > usenet at dfenton dot com http://www.dfenton.com/DFA/
From: The Frog on 6 Nov 2009 04:58 If your final application is going to be written in c# then store your data in sql server compact file (they are typesafe). This then just becomes another file that is shipped with the application. You can then store the data any way you wish inside the data tables. I would suggest that you integrate the encryption of the data table(s) with the generation of your license key. You could use a combination of public/private key pairs and a symmetric cipher like AES on the data itself. Anyone tries to 'read' the data will just see garbage output. Try this as an idea: Encrypt the data in the table(s) with an AES or similar cipher. Keep the AES key very long, and implement the decryption of the data as a function in the app - inline if you like. This way the data only ever lives unencrypted in memory and never on the hdd. The AES key itself stays with you at all times. Generate a public / private keypair, a really strong one, say 4096bit. Keep the private key private :-) What you want to do now is to generate a unique public / private keypair for each client / copy that uses the application. Sign (Encrypt) the AES key with your private key Encrypt the 'Signed Key' with the customers public key Ship the resulting key to the client, as well as their private key (keep a copy of both public / private keys of the client for yourself for later use and license re-issuing). The client now has their unique private key as well as your public key (safe to do), and a uniquely encrypted (the clients public key) and signed (by your private key) AES key. This way the key to the data is tied to their license. Now it would be possible to extract the AES key from this if the programmer were clever enough to disassemble the process and layer by layer strip away the keys to get to the AES key. If this process is compiled into your application as a 'standard' component, the data can stay encrypted except in memory (or even in memory if you load the encrypted data as a recordset into ram unchanged from the source). The user can 'use' the data but never really see the data. If your base data changes over time, like a phonebook will for example, you can issue another database file with a different AES key and ship it with the new license key(s) to the clients. If you are still worried about theft of the information then you need to work with a software house that specialises in these things. You could always place a 'marker' record in the data file that is unique to each customer but looks normal to the rest of the data. You might at least be able to tell where the leak came from! Hope this helps The Frog
From: David W. Fenton on 6 Nov 2009 14:33 Salad <oil(a)vinegar.com> wrote in news:75ednehyvMB0Hm7XnZ2dnUVZ_qZi4p2d(a)earthlink.com: > David W. Fenton wrote: > >> There is no encryption built into Access. >> > I thought there is in A2007. I don't believe you can encrypt > specific tables or fields; it's all or nothing. Well, yes. There was that form of encryption built into all previous versions of Jet that I know of (encryption was one of the parts of securing with Jet ULS, since otherwise, your data and code is viewable with a hex file viewer). But it doesn't encrypt data in data fields, which is what I understood the OP to be seeking. -- David W. Fenton http://www.dfenton.com/ usenet at dfenton dot com http://www.dfenton.com/DFA/
From: David W. Fenton on 6 Nov 2009 14:58
"Tony Toews [MVP]" <ttoews(a)telusplanet.net> wrote in news:4ai7f5p0bnqh6ak1q6nb4a2ptj9e2tn54s(a)4ax.com: > If under oh, say, 50 Mb, why not supply some sort of > encrypted text file and read the entire file into RAM into an > Enum. And see if it even needs to be sorted with a binary lookup > or not. Maybe running down 100K array sequentially is fast enough > for your requirements. He seems to be fixated on using ACCDB as his data store. And really doesn't want any actual advice, seems to me. -- David W. Fenton http://www.dfenton.com/ usenet at dfenton dot com http://www.dfenton.com/DFA/ |