For security, support passing the database password on the command line
With a Windows shortcut, one can customize how an Access database is launched. Many options are available including the specification of the workgroup, user name, and password: https://support.office.com/en-us/article/Command-line-switches-for-Access-558cfe1d-3c98-4292-bee8-1f5df9702bf1
Unfortunately, since the introduction of database passwords in Access 2007, this hasn't been added to the command line options. Without it, the user is prompted to enter the password when the database opens. This prevents letting users run the program without giving them the password and makes this security feature of limited value with ACCDB databases that can't support workgroup security.
Luke
shared this idea
18 comments
-
edwards142 commented
Thanks Luke, for sharing such an informative thing with us. I don’t any idea about passing the database password on the command line. But after reading out your post I came to know about this. Before this, I only know about one method to secure Access database i.e by encrypting Access database with password.
Great work, dear…!
-
Gianluca
commented
Actually, I did need to open a PW protected accdb on a shared drive from a task planner from within a Windows Server (night jobs) and solved the problem using VBScript:
Set accdbObj = Wscript.CreateObject("Access.Application")
accdbObj.OpenCurrentDatabase Path, , "myPassword""Normal" users don't have access to the server so I had no worries about a plain-text PW in my VBScript file.
-
Brian
commented
The ability to use SHELL to open and run an encrypted Access database is the requirement here.
NOT simply a windows shortcut with password embedded for convenience!
If the Password is accepted by the command line switch we can then open another Access application to run silently in the background IN ITS OWN THREAD!
this cannot be done using .OpenCurrentDatabase as this hijacks the original applications thread. -Try it yourself.
This will enhance security as now i must leave my application unprotected and un-encrypted to be able to use shell! -
Stewart Berman
commented
We use an encryption system from NetLib and would like to put the frontend password on the encrypted command line used to open the frontend and avoid the user getting prompted for it.
-
Stewart Berman
commented
The reason for having the ability to hide the frontend password in an encrypted program is to avoid making the password public. Once you have the password to a database you can remove all security from it including things like a startup form or macro. See:
http://saberman.com/Access/SAB_Lockdown/Index.htmUsing another database to open the frontend via Office Automation just kicks the can down the road. You can hack that one and then the frontend.
-
Adrian Bell (MVP)
commented
I still believe this one is a winner.
It may not be at the top of everybody's wish-list, but on the other hand is (probably) quite cheap to produce and would leave a more logical system to work within.
-
Adrian Bell (MVP)
commented
I take your point Mark, I really do, but if this is to be analysed seriously then I don't believe that can be done by avoiding questions.
The reason I asked the question (Is a password stored in a shortcut a less secure situation than a database with no password at all?) is that I see a number of scenarios where this parameter could be used to enable the use of password-protected databases more conveniently. If the worst that can be said against it is that it will surely be misused then I'd argue that is nobody's responsibility than the developer setting it up that way.
I'd certainly not recommend anyone leave their doorkeys under their mat in this day and age, but I'd hate to be unable to leave them with trusted neighbours because someone decided that the risk of people using their doormats outweighed the benefits of keys full-stop (or period for those across the pond). That seems a bit too nanny-ish from my perspective.
I have a real-world scenario where I upgrade my front end automatically by creating a CMD file on the fly and executing it. The file deletes itself when completed. Within that file is a call to run the specific (updated) front end file with Access and other parameters. A database password parameter would be useful to obviate the requirement to enter the password again for the operator. All operators at the company have to know the front end password anyway. Even to have a shortcut on the secured desktop of an operator is hardly a risk in this situation. Only that operator knows their own network password to get access to it.
Let us not forget that all scenarios are not equal. There are many where the level of danger, even for having it in a shortcut, is really not serious at all.
@Dolly.
I am not arguing that there are no ways to use automation to get at a database. Clearly there are. However, I don't believe that has any bearing on this discussion. This is about the ability to open a database, with a password, using the Access command. Although automation can be used instead in many situations, it would essentially require a starter application be developed to cover all your password-protected databases. Not a message I'd want to be putting out on the forums. -
Mark Burns
commented
@All,
Please don't misunderstand me here. I'm all for enhancing MS Access security and convenience at the same time. I'd dearly LOVE to see some API improvements for security, such as an .OpenDatabasePassword property for the Access.Application (and/or .DBEngine) objects. (set the password property value before the .opendatabase call, and the password is cleared by the opendatabase call, but only at the end, so it persists during the call - and can be passed down to child databases such as those in linked tables.)
If there were a convenient way to leverage that via the access application command line also, GREAT!...it's just that such methods are ripe with the potential for serious abuse/misuse - Dolly's excellent keys-under-the-doormat example being a wonderful one which underscores my concern about there potentially being unencrypted passwords in desktop shortcut command line strings - because we ALL just KNOW it WOULD HAPPEN like that in real life (we lazy/ignorant humans being who we are).
I'm only trying to make the point that such suggestions like this need deeper analysis, and the real answers here fall more into the "extend a security API to developers" category than they do as simpler request like "add a command-line password parameter"-type request.
-
Dolly
commented
If you need to grant access to a secured back-end you can easily do so, already, through simple automation (add it to a command button and voila!).
Even if such a command line switch existed, I'd NEVER use it.
I'm not saying leaving a back-end unsecure is good, and all mine are secured, but I would consider it just as irresponsible to go to the point of securing a back-end file and then leaving the password accessible directly in a shortcut that opens it. I also wonder if this wouldn't leave a developer liable for any hacking or damages. It's like leaving your house keys under the doormat at the front door (your insurance company won't cover you in the event of robbery).
-
Adrian Bell (MVP)
commented
@Frank.
You may want to explain how a plain text password stored in a shortcut is less secure than not being able to use a password at all - as pointed out in my previous comment. Unless anyone can explain (Logically - rather than simply expressing an opinion without foundation.) to the contrary, it seems clear that this suggestion, while not a perfect solution by any means, is better (or no worse at least) than the alternative (not having it) for each and every scenario that one could think of. After all, there is no reason for anyone to use it if they ever felt it wasn't a safe thing to use ;-)On the other hand, it can be a great feature for those that know what they're doing and can lever the best out of it.
-
Frank Rotolo
commented
In my opinion, storing plaintext password in a shortcut is a big security risk. I still don't understand why it's so difficult for MS to provide better security for Access.
-
Adrian Bell (MVP)
commented
Re-reading Luke's original post I can see why someone could misunderstand the suggestiopn here.
The introductory paragraph was simply that. To help people to understand how the parameters, generally, are invoked.
That was not intended to indicate that would be where this requested parameter would be used. At least not in my reading of it. Luke can correct me if I'm mistaken.
I suppose, if it came down to it, a password-protected database opened through a shortcut is still more secure than one that isn't password-protected. Still, if decent security is required we still need this parameter. We simply have to understand how best to use it.
-
Adrian Bell (MVP)
commented
Mark.
I have to disagree with that assumption.
No-one is suggesting that such a parameter be used from a shortcut. There are many many features that CAN be misused. That's a far cry from their being dangerous.
Actually, the way things stand is much more dangerous if you but think it through.Without a password parameter developers are forced to ensure the database has none!
WITH a password parameter a developer who knows what they're doing can use it perfectly safely.Far from compromising security, this gives the option of enhancing it.
-
Dolly
commented
@Stewart
In that case, you can already do so using an mde/accde to launch the db using automation. -
Stewart Berman
commented
The password can be hidden in a very small program that shells a command line to open the database. The password can be encrypted in the program and decrypted at the time the shell command is issued.
-
Dolly
commented
I think this would pose a serious security risk.
-
Mark Burns
commented
This is a great idea...if compromised security is your goal. Allowing such passwords on the command line of a shortcut will achieve only 2 things. 1) your desired outcome; 2) the easiest path to compromised database passwords in recorded history (right-click on the shortcut and hit Properties and voila! the password is revealed to ALL!)
-
Adrian Bell (MVP)
commented
I know we users always think everything's far more straightforward than they prove to be, I do believe this one should be easier to implement than most requests. I can be mistaken of course, but I think this one's a winner.
NB. My votes are all still tied up with many other items that are still under review, but this one will be the first to get any that become free.