Results 1 to 13 of 13
  1. #1
    PinkishToe is offline Novice
    Windows 10 Access 2013 32bit
    Join Date
    Dec 2021
    Posts
    3

    Preventing alteration of allowbypasskey property from an outside database

    Hi all,

    I have looked high and low but haven't come up with an answer to this yet.

    Using MS Access 2013, and an accdb file, how can you prevent users from changing the allowbypasskey from outside the database?

    I can secure it once the database is opened, and shuts down but a user can still changing it by referencing it from another Access project.



    So, is there a way to prevent changes to this property in a .accdb file?

    Thank you

  2. #2
    PinkishToe is offline Novice
    Windows 10 Access 2013 32bit
    Join Date
    Dec 2021
    Posts
    3
    I will mention, I am open to using accde files as well.

  3. #3
    isladogs's Avatar
    isladogs is offline MVP / VIP
    Windows 10 Office 365
    Join Date
    Jan 2014
    Location
    Somerset, UK
    Posts
    5,954
    Sorry to tell you this...but you can't prevent knowledgeable Access users re-enabling the shift bypass externally in an ACCDB file.
    ACCDE files will be more secure but not immune from hacking

    Never rely on the shift bypass feature alone for security. See my article Improve Security 2 - Mendip Data Systems (isladogs.co.uk)
    Colin, Access MVP, Website, email
    The more I learn, the more I know I don't know. When I don't know, I keep quiet!
    If I don't know that I don't know, I don't know whether to answer

  4. #4
    PinkishToe is offline Novice
    Windows 10 Access 2013 32bit
    Join Date
    Dec 2021
    Posts
    3
    Thanks for your input, however I still don't see how your solution would stop users from enabling the bypass, and with appropriate knowledge, showing the tables

  5. #5
    isladogs's Avatar
    isladogs is offline MVP / VIP
    Windows 10 Office 365
    Join Date
    Jan 2014
    Location
    Somerset, UK
    Posts
    5,954
    As already stated, it is IMPOSSIBLE to prevent anyone re-enabling the shift bypass externally
    My various suggestions are designed to add additional layers of security to make it that much harder to gain access

    Using an ACCDE file is one such step...
    BUT as the first part of the article clearly states:
    Access databases can NEVER be made 100% secure
    A capable and determined hacker can break any Access database given sufficient time and motivation.
    However, by erecting various barriers, it is certainly possible to make the process so difficult and time consuming that it isn't normally worth attempting.

    NOTE
    It is possible to make all tables deep hidden so these never appear in the navigation pane even if hidden & system objects are both ticked.
    That is an approach that I use regularly.
    However, even doing that isn't 100% secure. An expert can still overcome that approach externally
    Colin, Access MVP, Website, email
    The more I learn, the more I know I don't know. When I don't know, I keep quiet!
    If I don't know that I don't know, I don't know whether to answer

  6. #6
    CJ_London is online now VIP
    Windows 10 Access 2010 32bit
    Join Date
    Mar 2015
    Posts
    11,397
    I still don't see how your solution would stop users from enabling the bypass, and with appropriate knowledge, showing the tables
    As Colin has said, simple answer is - you can't stop knowledgeable users from enabling the bypass. Suggest you read the rest of Colin's articles on securing an access database. Point is because you can't you need to do other things such has hiding the navigation window, the ribbon etc. which Colin explains

    In summary of Colin's link, If you want to protect data, password protect the back end (if your app isn't split, that is your first problem, so split it). Use a .accde for the front end, don't use linked tables and don't use queries. Instead generate these objects in your code as and when required at runtime. Even then a knowledgeable user can possibly still find the password to the back end so obfuscate your code and use encryption for your passwords as well.

    You won't find an off the shelf solution (what would be the point of advertising 'this is how to break into my database'?) you need to make your own. You might find some suggestions if you google 'secure an access database' or similar.

  7. #7
    Join Date
    Aug 2022
    Location
    Kansas City
    Posts
    3
    We were all taught to write clean, understandable code and to build logically-named databases, tables and objects. All of which is coming back to bite us in the butt now. If your software is simple enough for a stranger to take over and support, it ius simple enough to hack. So, don't do that.

    db_Whatever, tbl_Clients, col_FirstName and sub_MonthlyUpdate should be dWh, tC, cFN and MU or something likewise abbreviated and non-obvious. COMMENT your code with explanative stuff, like:

    SUB MU
    ' Monthly Update
    ' tC = Client table
    ' cFN = First Name column

    If you use the FMS Inc. Code Tools product, which I highly recommend all their products, then you can run Code Cleanup and Code Delivery before you deploy your app. Those functions will remove all those nice explanative code comments (except ones that begin with '! which can remain in the deployed system, if need be). FMS Code Tools can also obfuscate (scramble) your Variable names to make your deliverable even more difficult to reverse engineer.

    After abbreviating your names, consider rubber tanks. You remember the story of how the Brits, on the run up to D-Day, made inflatable rubber tanks and put them on the beach in England to fool the Nazis into thinking the invasion would come from that location. Add fake code modules to your software. Hide all your real stuff from the Nav pane but leave some fake forms, tables, code modules and queries unhidden so the poor hackers can have something to do with their time. They will likely go through all your unhidden stuff before looking for hidden stuff.

    Add tables of data that look important but do nothing. Split your backend db into three or four dbs and encrypt each one with its own password. Don't forget to include a fake be db named something like EncryptKeys or something. Put fake data in it.

    Do not have your Installer routine put the software in a predictable place like C:\Program Files\ but instead bury it under a tree of fake but innocuously-named folders like C:\Learn Microsoft Word\Tutorials\Templates\Examples\ etc. where hackers wouldn't be inclined to look.

    In other words, use Armor AND Camouflage. Baffle em with BS. Waste their time.

  8. #8
    Micron is online now Virtually Inert Person
    Windows 10 Access 2016
    Join Date
    Jun 2014
    Location
    Ontario, Canada
    Posts
    12,737
    You remember the story of how the Brits, on the run up to D-Day, made inflatable rubber tanks and put them on the beach in England to fool the Nazis into thinking the invasion would come from that location.
    Thread is a bit old, but it was the Americans? The Brits did it in North Africa in 1942, well before D Day. IIRC, American Ghost Army unit operated in Germany in 1945, not on the shores of England. Brits never attempted to fool the Germans that the invasion would launch from the shores of England because that's where it did launch from. What was more important is keeping the landing location a secret.
    The more we hear silence, the more we begin to think about our value in this universe.
    Paraphrase of Professor Brian Cox.

  9. #9
    davegri's Avatar
    davegri is online now Excess Access
    Windows 11 Access 2019
    Join Date
    May 2012
    Location
    Denver
    Posts
    3,389
    This sort of "fake target" decoy construction was done in this country too during WWII. I can personally remember as a child, framed empty buildings with white painted screen exteriors in public parks in Baltimore. I asked my parents what they were and was told that it was to get the enemy to waste air raid bombs on useless targets. This seemed credible to me, as we also had to black out our home every night with "blackout curtains" to make it hard for enemy planes to distinguish targets at night.

  10. #10
    Join Date
    Jun 2010
    Location
    Belgium
    Posts
    1,035
    Seems a lot of trouble and time. In the times I still developed Access solutions I never used the internal tables but relied on a database that could secure the data. I teached the reponsable person for the application how to secure the data, so they could handle it themselves and more important: be responsable for the data security. The Access front-end was open-source code. I only made the user sign a paper that I was no longer responsable for the application in case of any changes to the front end. If you are the developer and user: use database software as a back-end (there is a lot of free stuff) that can handle security. And for the front-end: always keep a back-up so you can replace the files end users tinkered with. This will safe you a lot of time and work.

  11. #11
    Join Date
    Jan 2017
    Location
    Swansea,South Wales,UK
    Posts
    4,861
    Quote Originally Posted by Micron View Post
    Thread is a bit old, but it was the Americans? The Brits did it in North Africa in 1942, well before D Day. IIRC, American Ghost Army unit operated in Germany in 1945, not on the shores of England. Brits never attempted to fool the Germans that the invasion would launch from the shores of England because that's where it did launch from. What was more important is keeping the landing location a secret.
    No we did it over here just before DD. There was a program on this week about a Polish double agent that sent false information to the Germans about all the fake tanks, airplanes being moved to opposite Calais.
    The TV program showed clips of British troops moving inflatables around fields.
    Please use # icon on toolbar when posting code snippets.
    Cross Posting: https://www.excelguru.ca/content.php?184
    Debugging Access: https://www.youtube.com/results?sear...bug+access+vba

  12. #12
    Join Date
    Jun 2010
    Location
    Belgium
    Posts
    1,035
    Oh God, do they never stop talking about the war and the Germans. You seem all to be John Cleese. https://www.youtube.com/watch?v=yfl6Lu3xQW0

  13. #13
    isladogs's Avatar
    isladogs is offline MVP / VIP
    Windows 10 Office 365
    Join Date
    Jan 2014
    Location
    Somerset, UK
    Posts
    5,954
    Quote Originally Posted by NoellaG View Post
    Oh God, do they never stop talking about the war and the Germans. You seem all to be John Cleese. https://www.youtube.com/watch?v=yfl6Lu3xQW0
    ROFL
    Colin, Access MVP, Website, email
    The more I learn, the more I know I don't know. When I don't know, I keep quiet!
    If I don't know that I don't know, I don't know whether to answer

Please reply to this thread with any new information or opinions.

Similar Threads

  1. Toggle AllowByPassKey Property
    By Paul H in forum Database Design
    Replies: 18
    Last Post: 01-04-2024, 03:29 PM
  2. Latitude and Longitude alteration
    By tmcrouse in forum Access
    Replies: 3
    Last Post: 11-19-2015, 10:40 AM
  3. Create Property for AllowBypassKey
    By robbeh in forum Programming
    Replies: 2
    Last Post: 11-11-2014, 03:56 PM
  4. Process Alteration Database Design Methodology.
    By cap.zadi in forum Database Design
    Replies: 9
    Last Post: 10-30-2012, 03:51 AM
  5. Preventing changes in a split database file
    By kcollop in forum Database Design
    Replies: 2
    Last Post: 07-23-2012, 02:17 PM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
Other Forums: Microsoft Office Forums