By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
434,933 Members | 1,243 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 434,933 IT Pros & Developers. It's quick & easy.

Discussion: Comments on Alternative Bypass Key

TheSmileyCoder
Expert Mod 100+
P: 2,321
This thread was split off from How to change Shift key by another key to open file access.

It sounds to me like you will be spending time coding something that access already does, and for no extra benefit.
Oct 12 '12 #1
Share this Question
Share on Google+
17 Replies


NeoPa
Expert Mod 15k+
P: 31,492
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 ;-)
Oct 12 '12 #2

TheSmileyCoder
Expert Mod 100+
P: 2,321
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.
Oct 12 '12 #3

NeoPa
Expert Mod 15k+
P: 31,492
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.
Oct 12 '12 #4

TheSmileyCoder
Expert Mod 100+
P: 2,321
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.
Oct 12 '12 #5

NeoPa
Expert Mod 15k+
P: 31,492
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.
Oct 15 '12 #6

TheSmileyCoder
Expert Mod 100+
P: 2,321
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.
Oct 15 '12 #7

NeoPa
Expert Mod 15k+
P: 31,492
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.
Oct 15 '12 #8

Alias90
P: 23
I have crazy ideal " How to combine Shift key + another key to open access".
Expand|Select|Wrap|Line Numbers
  1. Iff((My ideal)='crazy','Sorry!','We can discuss detail')
Oct 16 '12 #9

TheSmileyCoder
Expert Mod 100+
P: 2,321
I never recommended not to disable the shift key. To be quite clear my recommendations are:
  1. Have a frontend client to reside on user PC
  2. Have a backend mdb/accdb server file on the network or a SQL server.
  3. Retain a frontend developer copy
  4. Create a copy, with
    • Navigation pane / Database window disabled
    • Special Hotkeys disabled (F11 for example)
    • Shift Key Disabled
    • Application dependent: Menus disabled
  5. MDE/ACCDE it
  6. 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.
Oct 16 '12 #10

TheSmileyCoder
Expert Mod 100+
P: 2,321
@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.
Oct 16 '12 #11

twinnyfo
Expert Mod 2.5K+
P: 3,284
NeoPa,

In post #2 above, you mention the potential for users to "accidentally" 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
Oct 16 '12 #12

NeoPa
Expert Mod 15k+
P: 31,492
@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
Oct 16 '12 #13

twinnyfo
Expert Mod 2.5K+
P: 3,284
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!
Oct 16 '12 #14

NeoPa
Expert Mod 15k+
P: 31,492
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 :-)
Oct 16 '12 #15

Expert Mod 2.5K+
P: 2,545
Excellent discussion on the pros and cons of disabling the bypass facility. @NeoPa - your analogy of the alternate bypass being like a hidden key for a physical door seems just about perfect to me (IMHO)!

There's a trade-off between the security of the product from prying fingers and ease of access for developers when needed.

@Smiley, having a SQL Server back-end does not of itself guarantee security at all unless the developer properly implements its table-level user security features, Active Directory integration, user permissions etc.

If you think I'm being a bit harsh about the use of SQL Server not necessarily being secure I have implemented several reporting systems using Access to connect to commercial system SQL Server instances originally found by me simply having a nose around with the built-in Windows ODBC administrator applet. Finding out what instances were available allowed me to try out connecting to them - and when connected via ODBC from Access in certain instances I was absolutely shocked to find that I had full read-write access to all the underlying SQL Server tables.

In one particular case (no names for obvious reasons) the developer of the product had simply used the username as the password for the SQL server connection - and given that it was an HR application this was not a good thing at all. Ultimately they introduced a strong random password for the connection string - but if you can obtain that password then connect to it with Access it still has read-write-delete access to all its tables as it did before!

That's not a criticism of SQL Server - just of developers who don't use the security features it provides. To use NeoPa's analogy, it's like having a full mortice lock on a front door strengthened with additional reinforcing bars and security chains then always leaving the back door unlocked when you go out - why bother?

-Stewart
Oct 18 '12 #16

NeoPa
Expert Mod 15k+
P: 31,492
Thanks for joining the discussion Stewart. Always good to hear from you (and especially so if you're supporting something I say :->).

You will probably not be surprised to hear that my SQL Server permissions (when I still managed one) were carefully set so that only those who should have update privileges had them. The point you make is a good one, and I expect Smiley would agree with you on that. His point being more that it provided the option of solid security rather than necessarily coming that way out of the box. At least that's how I read him, but I'll let him comment on that should he feel the need.

I must admit, just thinking about SQL Server administration brings a smile to my face. I've been working almost exclusively in Access for a while now and it doesn't give the BE features that SQL Server does. Then again, I find many situations where such power is not required and Access is perfectly fine for the job. It would be fun to work in it again some time though.
Oct 19 '12 #17

TheSmileyCoder
Expert Mod 100+
P: 2,321
Hi Stewart. Some good points you make there. My point was more that Access can only be brought to a certain level of security, there is so to speak a limit as to how secure it can be. If you want more secure, the next step would be a (well-setup) SQL backend.
That said, I still believe the level of security access can provide to be quite adequate for most purposes. I also think its important to compare it to the right product or counterpart.

Is the (realistic) counterpart a fully developed and maintained retail product, or is it a non-managed bunch of excel sheets?

I think in most (not all) cases where access is used, it replaces a growing bunch of excel worksheets, to provide a more manageable product. We are still moving from almost no security, to a level of more security. Not absolute security but there is no such thing as absolute security. There is no such thing as "Secure", there is however such a thing as to state that
Developer
"I the developer, has considered the security aspect, and taken REASONABLE measures to prevent fraud/hacking."
NeoPa
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.
The main point I wish to get across here is that you cannot disable the Shift Key in such a way that it can't be re-enabled.
I do agree that if its convenient for you, you can create an extra backdoor, and that it can make sense to have one. I just feel that these two matters are different in nature, and that one does not replace the other.

NeoPa
Anyway, next time you're in England come and visit so that I can apply that beating I promised :-D
Bring it on! :) Loser buys the beer!

NeoPa
@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 :->
Remember that the most interesting discussions are not the ones where we all agree. I have a great deal of respect for NeoPa and highly value his opinions.
Oct 22 '12 #18

Post your reply

Sign in to post your reply or Sign up for a free account.