|
security
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
MS Access program protectionpassword in the *.mdb file. I compiled it into a *.mde file. I also disabled the Bypass key (the SHIFT key to ignore startup options) while keeping a secret password protected back door for me. I did not use database password since there are lots of password crackers. But I do offer the user the option to use or not a password saved in a table. I think that this password will only stop the average people from snooping in his personal data. But a programmer could use a “Microsoft.Jet.oledb.4.0†connection to list the tables and queries and their fields, and therefore the data. Q1: Data protection I do not see how else to protect the data. But I can live with that flaw. I do not want to use “user and group accounts†since not everybody wants to use a password, and the user password popup will unfortunately always appear. Q2: Program protection Is it possible to decompile a *.mde file to extract the VBA code of forms, report and modules, re-edit forms and report? (I disabled the Bypass key (the SHIFT key) with AllowBypassKey property) Q3: Copy protection For now, I ask the user to E-mail me his MAC address. I hardcode his MAC address in the program (a String global variable), and the program reads all available MAC addresses of the computer for comparison. For now, it will do since I do not have lots of orders, and I have very little publicity. But when I will afford adds, and more frequent orders come, program keys will have to be automated. How could that be done? Should the program be able to communicate to a website database, some how? Michael <Mich***@discussions.microsoft.com> wrote:
>Q1: Data protection If your data has strict data security requirements then using an>I do not see how else to protect the data. But I can live with that flaw. I >do not want to use “user and group accounts” since not everybody wants to use >a password, and the user password popup will unfortunately always appear. Access BE (backend) MDB is not the solution. SQL Server or equivalent would be a far better solution. >Q2: Program protection MDE to MDB Conversion Service for Microsoft® Access>Is it possible to decompile a *.mde file to extract the VBA code of forms, >report and modules, re-edit forms and report? (I disabled the Bypass key (the >SHIFT key) with AllowBypassKey property) http://www.everythingaccess.com/mdeconversion.htm Wayne has stated he will require proof that you own the code. >Q3: Copy protection Tools available from sites such as sysinternals.com can crack any>For now, I ask the user to E-mail me his MAC address. I hardcode his MAC >address in the program (a String global variable), and the program reads all >available MAC addresses of the computer for comparison. For now, it will do >since I do not have lots of orders, and I have very little publicity. But >when I will afford adds, and more frequent orders come, program keys will >have to be automated. How could that be done? Should the program be able to >communicate to a website database, some how? method you use to store a future date anywhere on a system such as in the registry or a file. Unless it's encrypted. But even then if you delete the date from wherever it's stored your app may think it's just installed. Thus I prefer to limit the number of records in one key table such as 5 units or 50 volunteers but allow unlimited access for everything else. Once I get paid then I email them an encrypted file containing the number of records they are licensed for as well as their company name which goes on the bottom of every page of every report and frequently used forms. For more of my thoughts on this topic see the "Copy protection or how to safely distribute a demo Microsoft Access Application" page at http://www.granite.ab.ca/access/demo.htm I have thought of using the MAC address, once they've paid me the money, however I would definitely give them 10 uses before it no longer works. Just in case a problem happens on a weekend and I'm not available, etc, etc. Tony -- Tony Toews, Microsoft Access MVP Tony's Main MS Access pages - http://www.granite.ab.ca/accsmstr.htm Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/ Granite Fleet Manager http://www.granitefleet.com/ About Q2: Program protection
Do you know if the MDE to MDB conversion service retrieves the VBA password that I put? Does it re-enable the Bypass key? Since there is a way to decompile a MDE file, I saw that your reference also offers a product: “MDE Source Code Protector†http://www.everythingaccess.com/mdeprotector.htm I guess this would be one of two ways to protect the source code? The other way would be to remake the whole program using Visual Studio Visual Basic? (While connecting to Access or SQL Server table with Visual Basic) There is no other way to protect the source code? Thanks again, Michael ----------------------------------------------------------------------------------------- Show quoteHide quote > >Q2: Program protection > >Is it possible to decompile a *.mde file to extract the VBA code of forms, > >report and modules, re-edit forms and report? (I disabled the Bypass key (the > >SHIFT key) with AllowBypassKey property) There are *many* more tools to decompile .net apps than there are to
decompile mdes. Chris Michael wrote: Show quoteHide quote >The other way would be to remake the whole program using Visual Studio >Visual Basic? (While connecting to Access or SQL Server table with Visual >Basic) -- Message posted via AccessMonster.com http://www.accessmonster.com/Uwe/Forums.aspx/access-security/200906/1 =?Utf-8?B?TWljaGFlbA==?= <Mich***@discussions.microsoft.com> wrote
in news:5F855C01-EE5C-41E2-96B5-3E82C7DFB403@microsoft.com: That's not true. There is a way to evaluate the structure of the> Since there is a way to decompile a MDE file compiled code and create something that at least partly replicates the original code, but it's not going to look anything like the original code, though it may behave equivalently. Frankly, if you're worrying about someone stealing your MDE and decompiling it, I think you're completely nuts. Your work is simply not that valuable. Certainly, none of my work is that valuable. There are low cost tools on the Internet to remove the VBA password. If you
know where to look you can find out how to remove the VBA password for free. Since you didn't apply user level security to your file, anybody can reenable the shift key bypass on your file. Push Ctrl+G to open the immediate window, paste this line of code and hit enter: CurrentDb.Properties.Delete "AllowBypassKey" Close the db and reopen it while pushing the shift key. Your startup settings have been bypassed. In case your users don't know to use that 1 line of code, they can find free tools to set/unset the shift key bypass in any unsecured Access db. Albert Kallal's is pretty easy to find. It's recommended often in these groups. http://www.members.shaw.ca/AlbertKallal/msaccess/msaccess.html Since you didn't apply user level security to your file, anybody can use the link table manager to link to the tables and read the password you saved in 1 table. Depends on how far you want to go, but you can apply user level security to your file and nobody has to enter their user name and password when opening the db. They'd still be blocked from certain things because they aren't joined to the workgroup file you used to secure the db so don't have permissions. Chris Michael wrote: Show quoteHide quote >I just finished a MS Access 2003 program. The VBA code is protected with a >password in the *.mdb file. I compiled it into a *.mde file. I also disabled >the Bypass key (the SHIFT key to ignore startup options) while keeping a >secret password protected back door for me. I did not use database password >since there are lots of password crackers. But I do offer the user the option >to use or not a password saved in a table. I think that this password will >only stop the average people from snooping in his personal data. But a >programmer could use a “Microsoft.Jet.oledb.4.0†connection to list the >tables and queries and their fields, and therefore the data. > >Q1: Data protection >I do not see how else to protect the data. But I can live with that flaw. I >do not want to use “user and group accounts†since not everybody wants to use >a password, and the user password popup will unfortunately always appear. > >Q2: Program protection >Is it possible to decompile a *.mde file to extract the VBA code of forms, >report and modules, re-edit forms and report? (I disabled the Bypass key (the >SHIFT key) with AllowBypassKey property) > >Q3: Copy protection >For now, I ask the user to E-mail me his MAC address. I hardcode his MAC >address in the program (a String global variable), and the program reads all >available MAC addresses of the computer for comparison. For now, it will do >since I do not have lots of orders, and I have very little publicity. But >when I will afford adds, and more frequent orders come, program keys will >have to be automated. How could that be done? Should the program be able to >communicate to a website database, some how? -- Message posted via AccessMonster.com http://www.accessmonster.com/Uwe/Forums.aspx/access-security/200906/1 How can I apply user level security to my file without creating a user and
still not have to enter user name and password when opening the db. Thanks, Michael Show quoteHide quote "Chris O'C via AccessMonster.com" wrote: > There are low cost tools on the Internet to remove the VBA password. If you > know where to look you can find out how to remove the VBA password for free. > > Since you didn't apply user level security to your file, anybody can reenable > the shift key bypass on your file. Push Ctrl+G to open the immediate window, > paste this line of code and hit enter: > > CurrentDb.Properties.Delete "AllowBypassKey" > > Close the db and reopen it while pushing the shift key. Your startup > settings have been bypassed. > > In case your users don't know to use that 1 line of code, they can find free > tools to set/unset the shift key bypass in any unsecured Access db. Albert > Kallal's is pretty easy to find. It's recommended often in these groups. > > http://www.members.shaw.ca/AlbertKallal/msaccess/msaccess.html > > Since you didn't apply user level security to your file, anybody can use the > link table manager to link to the tables and read the password you saved in 1 > table. > > Depends on how far you want to go, but you can apply user level security to > your file and nobody has to enter their user name and password when opening > the db. They'd still be blocked from certain things because they aren't > joined to the workgroup file you used to secure the db so don't have > permissions. > > Chris > > > Michael wrote: > >I just finished a MS Access 2003 program. The VBA code is protected with a > >password in the *.mdb file. I compiled it into a *.mde file. I also disabled > >the Bypass key (the SHIFT key to ignore startup options) while keeping a > >secret password protected back door for me. I did not use database password > >since there are lots of password crackers. But I do offer the user the option > >to use or not a password saved in a table. I think that this password will > >only stop the average people from snooping in his personal data. But a > >programmer could use a “Microsoft.Jet.oledb.4.0†connection to list the > >tables and queries and their fields, and therefore the data. > > > >Q1: Data protection > >I do not see how else to protect the data. But I can live with that flaw. I > >do not want to use “user and group accounts†since not everybody wants to use > >a password, and the user password popup will unfortunately always appear. > > > >Q2: Program protection > >Is it possible to decompile a *.mde file to extract the VBA code of forms, > >report and modules, re-edit forms and report? (I disabled the Bypass key (the > >SHIFT key) with AllowBypassKey property) > > > >Q3: Copy protection > >For now, I ask the user to E-mail me his MAC address. I hardcode his MAC > >address in the program (a String global variable), and the program reads all > >available MAC addresses of the computer for comparison. For now, it will do > >since I do not have lots of orders, and I have very little publicity. But > >when I will afford adds, and more frequent orders come, program keys will > >have to be automated. How could that be done? Should the program be able to > >communicate to a website database, some how? > > -- > Message posted via AccessMonster.com > http://www.accessmonster.com/Uwe/Forums.aspx/access-security/200906/1 > > Joan Wild has the instructions here:
http://www.jmwild.com/SecureNoLogin.htm Chris Michael wrote: Show quoteHide quote >How can I apply user level security to my file without creating a user and >still not have to enter user name and password when opening the db. -- Message posted via AccessMonster.com http://www.accessmonster.com/Uwe/Forums.aspx/access-security/200906/1 So if the buyer swaps out a bad nic card or replaces his/her pc with a new
one, they have to come back to you to recode and reissue their app? Do you tell them this when they buy your app or do you tell them after your app stops working (or accuses them of being a pirate by making an illegal copy)? Either way you'll make them mad but 1 of those choices will make them madder. Chris Michael wrote: >Q3: Copy protection >For now, I ask the user to E-mail me his MAC address. I hardcode his MAC >address in the program (a String global variable), and the program reads all >available MAC addresses of the computer for comparison. For now, it will do >since I do not have lots of orders, and I have very little publicity. I tell them in advance about the MAC address restriction. And I also tell
them that I allow up to 5 MAC address change. I do not think that somebody would have to change 5 times their network card. They would have to be very unlucky with the same computer. After all, the price of that program is 15$ (even though I spent a few years perfecting this program, on and off part time). If they like the program, they will pay if they need to change it more than 5 times. Michael Show quoteHide quote "Chris O'C via AccessMonster.com" wrote: > So if the buyer swaps out a bad nic card or replaces his/her pc with a new > one, they have to come back to you to recode and reissue their app? > > Do you tell them this when they buy your app or do you tell them after your > app stops working (or accuses them of being a pirate by making an illegal > copy)? Either way you'll make them mad but 1 of those choices will make them > madder. > > Chris > > > Michael wrote: > >Q3: Copy protection > >For now, I ask the user to E-mail me his MAC address. I hardcode his MAC > >address in the program (a String global variable), and the program reads all > >available MAC addresses of the computer for comparison. For now, it will do > >since I do not have lots of orders, and I have very little publicity. > > -- > Message posted via http://www.accessmonster.com > > It's not hard to clone a mac address or find out how. Googling clone mac
address I get almost 700K hits. So 1 buyer pays $15 for one copy and hands out unlimited copies of your app and the mac address it works for to everybody who wants it. Chris Michael wrote: >I tell them in advance about the MAC address restriction. =?Utf-8?B?TWljaGFlbA==?= <Mich***@discussions.microsoft.com> wrote
in news:75B90C5D-23EF-4615-BC46-E33941DCB7D8@microsoft.com: If the Jet ULS username is the same as the user's Windows logon, you> I > do not want to use ƒ ouser and group accountsƒ since not > everybody wants to use a password, and the user password popup > will unfortunately always appear. can pass \usr %USERNAME% in the command line of the shortcut that launches your Access app. Users with passwords will prompted for it, those without a password will not. =?Utf-8?B?TWljaGFlbA==?= <Mich***@discussions.microsoft.com> wrote
in news:75B90C5D-23EF-4615-BC46-E33941DCB7D8@microsoft.com: If you're not encrypting the MDE front end, or encrypting the MAC> Q3: Copy protection > For now, I ask the user to E-mail me his MAC address. I hardcode > his MAC address in the program (a String global variable), and the > program reads all available MAC addresses of the computer for > comparison address in your string constants, it's going to be available in plain text for anyone browsing your MDE with a binary editor. Tony encrypts his strings when he writes them into his modules so he doesn't have to encrypt the MDE (so that it will still compress when zipped). I believe that it's better to encrypt everything so as not to draw attention to the particular strings that are encrypted. Remember, constants are compiled literally into the code, so any constant will be there in the compiled p-code every time it is used, not just in the place where its value is declared. "David W. Fenton" <XXXuse***@dfenton.com.invalid> wrote: The strings are encrypted and obfuscated. Chunks of the encryption>Tony encrypts his strings when he writes them into his modules so he >doesn't have to encrypt the MDE (so that it will still compress when >zipped). I believe that it's better to encrypt everything so as not >to draw attention to the particular strings that are encrypted. password are constants in different modules. ABC here DEF there, GHI over there and so forth. Tony -- Tony Toews, Microsoft Access MVP Tony's Main MS Access pages - http://www.granite.ab.ca/accsmstr.htm Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/ Granite Fleet Manager http://www.granitefleet.com/
Show quote
Hide quote
"Tony Toews [MVP]" <tto***@telusplanet.net> wrote in For non-downloaded front ends, would you consider Access encryptiongnews:nhvr25108mdvr1913o1vk1o28rq9315ngl@4ax.com: > "David W. Fenton" <XXXuse***@dfenton.com.invalid> wrote: > >>Tony encrypts his strings when he writes them into his modules so >>he doesn't have to encrypt the MDE (so that it will still compress >>when zipped). I believe that it's better to encrypt everything so >>as not to draw attention to the particular strings that are >>encrypted. > > The strings are encrypted and obfuscated. Chunks of the encryption > password are constants in different modules. ABC here DEF > there, GHI over there and so forth. for it? I have a client who needs to store credit card numbers, and it's going to be encrypted in the data table, so that means I have to distribute an MDE and I'm going to encrypt the front end. There's never any real need to download the front end, except for the occasional update, and I have broadband and they have broadband, so the full-size 5.5MB front end is not a terrible problem. "David W. Fenton" <XXXuse***@dfenton.com.invalid> wrote: I have no expertise on Access encryption so I don't know how good it>For non-downloaded front ends, would you consider Access encryptiong >for it? I have a client who needs to store credit card numbers, and >it's going to be encrypted in the data table, so that means I have >to distribute an MDE and I'm going to encrypt the front end. There's >never any real need to download the front end, except for the >occasional update, and I have broadband and they have broadband, so >the full-size 5.5MB front end is not a terrible problem. is. That said I've used the MS Crypto functions in the Auto FE Updater and it seems to have worked. So maybe that would be a solution to encrypt just that field. Tony -- Tony Toews, Microsoft Access MVP Tony's Main MS Access pages - http://www.granite.ab.ca/accsmstr.htm Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/ Granite Fleet Manager http://www.granitefleet.com/ "Tony Toews [MVP]" <tto***@telusplanet.net> wrote in Back in 2004 I was using your updater and was encountering problemsnews:gh7b35h8v5l9ube3fi15jdbdi427ueko3u@4ax.com: > I've used the MS Crypto functions in the Auto FE > Updater and it seems to have worked. So maybe that would be a > solution to encrypt just that field. with different versions of Win2K returning different results for the encryption of the password. At the time, you were looking into it. Did you resolve it eventually? "David W. Fenton" <XXXuse***@dfenton.com.invalid> wrote: Oh yes, it was sheer stupidity on my part. I was passing different>> I've used the MS Crypto functions in the Auto FE >> Updater and it seems to have worked. So maybe that would be a >> solution to encrypt just that field. > >Back in 2004 I was using your updater and was encountering problems >with different versions of Win2K returning different results for the >encryption of the password. At the time, you were looking into it. >Did you resolve it eventually? arguments when encrypting vs decrypting. I posted about the update and I think you asked me that question in the newsgroup. <smile> Tony -- Tony Toews, Microsoft Access MVP Tony's Main MS Access pages - http://www.granite.ab.ca/accsmstr.htm Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/ Granite Fleet Manager http://www.granitefleet.com/
Show quote
Hide quote
"Tony Toews [MVP]" <tto***@telusplanet.net> wrote in Ah, so it wasn't some exotic difference between the encryptionnews:c1ae35h16tc9sjrhmg4mipufvl2chp15s4@4ax.com: > "David W. Fenton" <XXXuse***@dfenton.com.invalid> wrote: > >>> I've used the MS Crypto functions in the Auto FE >>> Updater and it seems to have worked. So maybe that would be a >>> solution to encrypt just that field. >> >>Back in 2004 I was using your updater and was encountering >>problems with different versions of Win2K returning different >>results for the encryption of the password. At the time, you were >>looking into it. Did you resolve it eventually? > > Oh yes, it was sheer stupidity on my part. I was passing > different arguments when encrypting vs decrypting. > > I posted about the update and I think you asked me that question > in the newsgroup. <smile> libraries on different versions of Windows. If you aren't at bat, you never strike out, so making a mistake like that is expected, since you're actively programming on a regular basis.
Show quote
Hide quote
"David W. Fenton" <XXXuse***@dfenton.com.invalid> wrote: Oh, I have no problem admitting I make mistakes. <smile> I was>>>> I've used the MS Crypto functions in the Auto FE >>>> Updater and it seems to have worked. So maybe that would be a >>>> solution to encrypt just that field. >>> >>>Back in 2004 I was using your updater and was encountering >>>problems with different versions of Win2K returning different >>>results for the encryption of the password. At the time, you were >>>looking into it. Did you resolve it eventually? >> >> Oh yes, it was sheer stupidity on my part. I was passing >> different arguments when encrypting vs decrypting. >> >> I posted about the update and I think you asked me that question >> in the newsgroup. <smile> > >Ah, so it wasn't some exotic difference between the encryption >libraries on different versions of Windows. > >If you aren't at bat, you never strike out, so making a mistake like >that is expected, since you're actively programming on a regular >basis. rather annoyed at myself for making such a simple, foolish mistake that took me so long to figure out. Tony -- Tony Toews, Microsoft Access MVP Tony's Main MS Access pages - http://www.granite.ab.ca/accsmstr.htm Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/ Granite Fleet Manager http://www.granitefleet.com/
Show quote
Hide quote
"Tony Toews [MVP]" <tto***@telusplanet.net> wrote in I think of this class of error as the "is it plugged in?" type.news:spji35tlrko25jv8pnsrrkqtf3tnptkfqj@4ax.com: > "David W. Fenton" <XXXuse***@dfenton.com.invalid> wrote: > >>>>> I've used the MS Crypto functions in the Auto FE >>>>> Updater and it seems to have worked. So maybe that would be a >>>>> solution to encrypt just that field. >>>> >>>>Back in 2004 I was using your updater and was encountering >>>>problems with different versions of Win2K returning different >>>>results for the encryption of the password. At the time, you >>>>were looking into it. Did you resolve it eventually? >>> >>> Oh yes, it was sheer stupidity on my part. I was passing >>> different arguments when encrypting vs decrypting. >>> >>> I posted about the update and I think you asked me that question >>> in the newsgroup. <smile> >> >>Ah, so it wasn't some exotic difference between the encryption >>libraries on different versions of Windows. >> >>If you aren't at bat, you never strike out, so making a mistake >>like that is expected, since you're actively programming on a >>regular basis. > > Oh, I have no problem admitting I make mistakes. <smile> I was > rather annoyed at myself for making such a simple, foolish mistake > that took me so long to figure out.  
Other interesting topics
Need Help Adding user lvl Security to 2007 version
Understandable documentation regarding Access DBA security Unable to compact/repair because I have it opened users set their own password Access security behavour Comments for Software Copy Protection Solutions Allow a Disk as a Trusted Location or disable it entirely Workgroup permissions for Access 97 DB (permissions error) Secured Access to Forms Trace a user in network version of database |
|||||||||||||||||||||||
