Discussion: Comments on Alternative Bypass Key

**NeoPa** · Oct 12 '12, 12:22 PM

That's perfectly true of course Smiley, but sometimes a complete lockdown is not exactly what a developer is after. Sometimes, a little obfuscation is all that is required. It all depends on the perceived threat levels, which depends on the know-how of the expected users. I know, for instance, that much of the work I do for a particular company has much more threat from accidentally keeping the Bypass key held down in order to enter the upper-case password, than it ever would from one of the users attempting to get into the details of the system. When they are successful in breaking into the system they need to call me to get the system to work again ;-)

**TheSmileyCoder** · Oct 12 '12, 12:37 PM

Disabling the Shift Key makes perfect sense, and I would recommend that in most if not all cases.

Adding a secondary type of shift key seems to make little sense, since it doesn't change the fact that the Shift Key can still be re-enabled by a user knowing what to do.

Maybe I am missing something.

**NeoPa** · Oct 12 '12, 02:02 PM

If an analogy is locking up your house when you leave it empty :

Having your project start automatically into a form is equivalent to locking the front door with a Yale lock. It will stop most thieves from getting in. It will particularly discourage crimes of opportunity. Insurance companies tend to insist you use a mortice lock however, if you want cover.

A mortice lock is equivalent to disabling the Bypass key. It will stop all but the very determined thief. Such a thief has the tools to get in however.

Having the Bypass key disabled, but implementing an alternative entry strategy, is like using the mortice lock, but hiding a key where only you know where it is. Still much more secure than relying on the Yale lock alone, but theoretically not as secue as the mortice lock without any key available. As long as the key is not easily found or guessed though, the strength is roughly equivalent to the mortice lock.

The important issue here is that most thieves (crackers) would not expect for there to be a hidden key available. Once that is suspected it is not too hard to crack. Personally, if I were approaching such a database in order to gain access, I would be looking at finding a way to re-enable the bypass key rather than hunting around for some alternative key somewhere that may or may not exist. The important point here is how many people know about the standard Office Bypass key as opposed to those that might know of the code applied by a particular developer in order to provide a similar facility to gain entry to their own project. You will see that the numbers of people with the former knowledge should vastly outweigh those with the latter. If you don't know about it then you won't take advantage of it.

I know the analogy used is imperfect. It's actually quite common for householders to store a key somewhere hidden on their property when they leave, yet the same cannot be said about an alternative Bypass facility in Access projects. This is rare enough to be effective up to the point of disabling the Bypass key. I hope that makes sense.

**TheSmileyCoder** · Oct 12 '12, 05:14 PM

I think your analogy is a bit flawed.

I get the point up to the fact that disabling the shift key is equivalent to adding a lock to your door.

The problem is that the lock can be picked by anyone with the right tools. This however doesn't mean we shouldn't have a lock of course.

Your idea of adding a secondary method of getting into the database is the equivalent of adding an extra door, and securing it differently. It doesn't increase the security or difficulty of breaking through the first door.

If you want, you can increase the security of the first door slightly by adding a database password. However as everyone who needs to use the database needs to have a key (And the SAME key at that) I find it doesn't add much security at all. If you give the password to 30 users, you pretty much (in my opinion) might as well write it on your screensaver, and the question at that point is whether the difficulty and annoyance of a password is worth the tiny bit of extra security.

If you really need that extra security you can use a SQL server backend to secure your data.

**NeoPa** · Oct 15 '12, 12:41 AM

Like most analogies Smiley, mine wasn't perfect (although I would contend it is very much closer than the extra door idea). Anyway, I'm not sure you recognised the point I was trying to illustrate.

Because there are tools for experts to use to break in, doesn't mean that it is therefore 100% insecure. That point being recognised, and in a scenario where you are attempting to protect a project from users who don't have those tools (and experience teaches us that this situation is far from rare), a Bypass key of your own choosing is less likely to be used successfully to break into the project than the standard one of the Shift key.

**TheSmileyCoder** · Oct 15 '12, 07:24 AM

If we stick to the 2 door concept for a second.

Door 1 as you described is the door with the Shift Bypass key enabled.

I say that your method of adding a secondary bypass key is the equivalent of adding another door, because the secondary bypass does not in any way increase the security of the first door.

I would argue that your second door by itself could be considered more secure then the first door, since it relies on perhaps a password or key combination that only you know.

The problem however is still that the first door still remains, so from my perspective it seems like you are complicating matters and gaining no extra security. As you the developer is skilled enough to disable the Shift bypass you are surely skilled enough to re-enable it, and thus you (from my perspective) have no need of adding a second door.

**NeoPa** · Oct 15 '12, 11:01 PM

But, by creating a second (hidden) door, you allow the first door to be locked a lot more securely (I think you'd agree that, even though disabling the Bypass key is not a guarantee of absolute security, it is nevertheless much more secure than not doing so), while at the same time ensuring convenient access for the developer.

**Alias90** · Oct 16 '12, 06:31 AM

I have crazy ideal " How to combine Shift key + another key to open access".

Code:

Iff((My ideal)='crazy','Sorry!','We can discuss detail')

**TheSmileyCoder** · Oct 16 '12, 07:49 AM

I never recommended not to disable the shift key. To be quite clear my recommendations are:

Have a frontend client to reside on user PC
Have a backend mdb/accdb server file on the network or a SQL server.
Retain a frontend developer copy
Create a copy, with
- Navigation pane / Database window disabled
- Special Hotkeys disabled (F11 for example)
- Shift Key Disabled
- Application dependent: Menus disabled
MDE/ACCDE it
Distribute it using a automated update system

In this scenario I don't see the benefit of an extra door. Maybe our discussion is simply that we look at the above slightly different, because I see no benefit of the extra door. Even if you should need to access one of the distributed files in a debugging case, you can still re-enable the shift key and get into the files.

**TheSmileyCoder** · Oct 16 '12, 07:51 AM

@Alias90:

There is no need to be sorry for starting a discussion. That is how we learn, and improve. NeoPa and me, having both worked for years in access / office, can still have a difference of opinion. Don't take our discussion as a fight, I am sure we both respect each others professional opinion.

**twinnyfo** · Oct 16 '12, 11:23 AM

NeoPa,

In post #2 above, you mention the potential for users to "accidental ly" engaging the bypass key in anticipation of entering their password. In you case, would it be possible (or realistic) to disable the bypass key, then have the opening form pop up, and on the On Open Event (after the locked down database is already open in a more secure mode), re-enable the Bypass key? Wouldn't this prevent users from unsecuring the DB, but then allow then to use the shift key for their password?

To All: This is a very interesting post, and I have considered locking down my DB by disabling the bypass key, but as explained by others above, the users connected to my DB have little if any DB design knowledge, and even less concern for hacking or damaging the application. our DB is stored on a secure server, so we handle security from that direction.

Warm regards,
twinnyfo

**NeoPa** · Oct 16 '12, 04:16 PM

@Twinny.
I'm not sure what you're thinking here. If what you suggested had any effect at all it would be an undesired one. Re-enabling the Bypass key at that time would have no effect for the rest of the session - as the Bypass key only has any effect when opening the database at the start, but it would leave the database unprotected for the next time it was opened. It's good to consider different approaches, but I'm afraid I see no benefit to this idea.

@Alias90.
As Smiley says, we have been visiting here together for a long while now and I've seen too much of his work to have anything less than respect for his comments - even when, as in this case, we don't see things from the same perspective. Don't worry. I'm sure by the time I've beaten him over the head a few hundred times with a large stick he'll come around to my way of thinking :->

@Smiley.
Sometimes having a fully locked down database can be inconvenient for a developer. I know that, while I know how to create such a database, I rarely do so with clients as the the benefits don't (for me) outweight the costs (in convenience for me as a regular developer). Also, when I work with a client I generally let them own the work produced (non-exclusively - so they cannot stop me using similar ideas and design elsewhere). Were I selling a product on the open market my approach would certainly be different.

You will never appreciate the benefit of the approach requested by Alias90 unless you can accept that not everyone believes all databases should be locked down securely in all situations. The situation you outline is only one of many possible situations people are working within. It's certainly the most secure, but it does have an undesirable side-effect of making the development less convenient and more fraught with risk for the developer. I'm sure you have set up procedures to minimise those in your environment, but not everyone will be in such a well set up position.

Anyway, next time you're in England come and visit so that I can apply that beating I promised :-D

**twinnyfo** · Oct 16 '12, 05:55 PM

NeoPa,

Thanks for the clarificaiton. To be honest, I did not understand how the Bypass procedure worked. But, now I have a better idea. As I've said before on this site, glad to have learned something today!

**NeoPa** · Oct 16 '12, 11:30 PM

Good to hear Twinny. I was trying not to sound critical of your suggestion. What impresses me is the consideration of new ideas and attempts to make things work even if they do not do so by default, so always worth asking the questions :-)