You can use your favorite social network to register or link an existing account:
Or use your email address to register without a social network:
Sign in with these social networks:
Or enter your username and password
Forgot your password?
Yes, please link my existing account with for quick, secure access.
No, I would like to create a new account with my profile information.
Tips
How-to
News
Videos
Stories
In last week’s post, I talked at a high-level about some engine-level changes we’ve made to Access. This week, I’ll talk about changes to the security model that sits on top of that engine, and crosses into the UI as well. Starting next week, I’ll be going into the UI changes and all the other new stuff we’ve done in the product.
Fewer modal prompts on boot (by default) and disabled mode
In Access 11 based on the configuration of the machine when a user opened a database, he or she encountered 3 to 4 modal startup prompts which, to say the least, was cumbersome. In Access 12 we've been able to weed out most of these startup prompts by improving the application's trust evaluation model (improvements to the Office Macro security model) and making core improvements to the client. When a user opens a database, Access 12 will assess the trust around this database by using the following pieces of evidence:
o Location of the database file: Using the Office trust center, users can denote certain folders (local or remote) as trusted locations. This is an easy way to tell the application that the Office file within this folder is trusted and hence is safe to launch.
o Code signatures: The good old signature model still exists. A user can digitally sign a database with his or her code certificate and share such a signed database with other users. Users who trust the certificate can then launch any Office file with a valid signature as a trusted file.
By examining these pieces of evidence associated with a database, the Access client then makes a decision to trust the database or not. If trusted, the database will launch fully enabled. If the database is not trusted, Access will still open the database, but components like VB code, macros, pass through queries and the like will be disabled. This disabled state of the database will allow the user to examine the file, without the fear of code execution. If the user decides the file is trustable after examining it, she can choose to trust it and thereby enable all code, etc. This trust model is shared across the Office suite, so will be familiar to all Office users.
Safe Macros
When in disabled mode, any set of custom logic even in simple and potentially safe cases like navigating to another Access object (hmm … isn't this the switchboard scenario) would be disabled. Access 12 has created a sandboxed coding mechanism for cases like this using the Access Macro language. Macros have been part of access since version 1, but are rarely used by developers today, since they’re essentially a subset of VBA. In Access 12, however, we’ve been able to use that subset to our advantage by marking many of the macro actions as “safe”. These safe macro actions can then be stitched together to provide logical components that still function if the database is opened in disabled mode. This subset of safe macros is not meant to completely replace the need for code, but to provide basic and safe operations within disabled mode.
Improved encryption with database passwords
In previous versions Access depended on JET's ability to encode a database with its proprietary encoding scheme. Though the scheme served its purpose when it was first released, the current market provides better and tougher encryptions algorithms that can be used. The same goes with the "Database password" feature, JET would allow only users that knew the password to open the database, but would do little to encrypt the file when a password was set. In Access 12 (by improving the new engine), we've combined the two features into "Encrypt with database password" for new file formats (for backwards compatibility reasons the old file formats would still support the old proprietary scheme). This feature allows users to encrypt a database using one the many Office supported algorithms, bringing encryption in Access on par with the new encryption models for other Office applications.
User level security
Since JET is a file based database system where users need physical access to the file to operate on their data, the concept of user level security in Jet to assign different levels of user access to the data within the same file was not recommended. To have multiple people use the database but with different data access privileges, the recommended practice was to move this data to a centralized service like SQL server or SharePoint lists. However, Jet has had this feature for some time and it has worked OK for usability and custom navigation scenarios but isn’t recommended for actual security. To help promote using truly secure user-level security, ACE will no longer support the JET concept of user level security for new file formats (for backwards compatibility reasons ACE will continue to support JET user level security for old file formats). To help maintain the scenarios around custom navigation the Access UI (including the NavPane) will allow solution creators to completely customize the navigation experience.
We believe that the security work in Access 12 will both make the product more secure through things like the improved encryption and clearer user-level security, and will make security easier to manage through the new trust model and “safe” macros. In the next post, I’ll start talking about the feature changes we’ve made to the product by describing how report design has changed.
Comments: (36) Collapse
"ACE will no longer support the JET concept of user level security for new file formats " I'm guessing that ACE is the name of the new JET database format??? Since you are no longer supporting user-level security in "ACE," I presume that means that you are continuing to enhance the ADP concept to access SQL Server data? Could you please comment on that for us ADP/ SQL Server users? Will ADPs get the same enhancements as the MDBs?
Gosh. It's hard to know what to say. (1) The macro thing. IMHO, no experienced developer is going to start coding to macros, just so their database has minimal functionality in a locked-down mode. How many professionally designed, turnkey Access applications can work to any acceptable degree, without VBA? My bet is, a very small number. This is not a feature that I would have envisaged in a hundred years. I do not use macros now, and I do not plan to use them in the future, whatever changes have been made with them. This is not because "they are a subset of VAB", as you disengeniously state; it is because they do not have any proper control structures, error handling, or other things that properly-written code should have. (2) The new trust model - will you still support the AutomationSecurty property? I use that to luanch my product from a script, bypassing all the security warnings, regardless of the PC's macro security level. It has worked fine for me, so far. (3) User level security. Jet had one of the most sophisticated security models in any desktop database. It was only let down by some simple mistakes that could have been fixed quite easily. (I'm not guessing, I know exactly how it all works under the hood, and how it could be changed, but this is not the place for that discussion.) Instead, you seem to be saying that you have thrown the whole model out, completely! (when people use the new file format) Is that so? If so, what have you repaced it with? I must say, this is not what I expected. I expected that you would address the actual problems that actual people actually have when they actually try to create a secured database! Most of those probems revolve around workgroup files, and their place in the process. Your post did not mention workgroup files. Are they still used? Do they work the same way? I'm disappointed. Please lose sleep about that! :-)
I use one Macro... it actually just runs a VBA subroutine though. It's only there so I can easily run a subroutine that I don't keep a button for on the main form. But could such a macro be marked safe?
You’re doing away with ULS *entirely*? What a shame. I’ve never used it for security, but find it a useful tool for the custom navigation you speak of. Now what will I do? Although Access 12 will allow customization in the NavPane, how will this be accomplished with multiple groups of users and the need to have a different NavPane for each?
Erik,
I'm both concerned and puzzled. First you say, "ACE will no longer support the JET concept of user level security for new file formats..." Then you say, "Access 12 will both make the product more secure through things like the improved encryption and clearer user-level security..." My puzzle is whether you are eliminating User Level Security all together or not. My concern is that you are eliminating it. One of the strengths of Access is that developers can create applications in a wide variety of ways. User Level Security has provided one of the tools that developers have at their disposal to allow users access to certain types of data while, at the same time, denying them access to other data. The Jet ULS model gives them that ability. If you eliminate it all together and a company chooses to NOT put their data in SQL Server and/or Share Point, then you have effectively removed this ability. That is NOT a good idea. Microsoft had high hopes that the Access user community would move over to MSDE. That didn't happen. The hope that they will all mover over to SQL Server or Share Point may well suffer the same fate. If you remove Jet ULS altogether, then you leave developers with no way to provide the kind of rich user interfaces and access levels that they want and need. I sure hope you will reconsider this choice. Lynn Trapp
Access MVP
Erik: I have long thought that Jet ULS suffered from two problems:
1. It has an aspect of "pretty good but not 100% secure" coupled with "not well understood and applied by casual Access devs". But often the "pretty good" is good enough, and the "not 100% secure" is OK. Meanwhile, part of the reason for its misapplication is the historically weak docs, and the degree to which the UI frustrates attempts to get the full overview of current security settings. I myself ended up developing a tool (available at grahamwideman.com) to reveal "at a glance" the current state of users, groups and permissions, mostly in order to learn how it *really* behaves... which is ultimately sensible but not at all transparent in the UI. 2. It's *highly* useful in a scenario that gets very little attention, and isn't "mainstream ULS" so to speak. Jet allows us to write standalone apps (with DAO) that to the user appear to have "document files" (actually mdbs which the app reads and write using SQL), and which can also be very usefully viewed/queried *RO* by the user in Access (ie: freedom to browse the data without worry of damaging it). While you can of course implement the permissions aspect of this in MSDE, it's a totally different file management model from the perspective on an end-user (of my apps). Bottom line: I *hope* that whatever file-based DB engine we go forward with will continue to support the scenario just mentioned, with the ability to distinguish users and permissions and at the same time allow end-users to treat the files like any other doc files. If encryption is better, great, but much of the time I (and many clients) don't care. (And the cases where they *do* care often coincide with cases where a server solution is acceptable or desirable).
Graham wrote:
> "pretty good but not 100% secure" The really frustrating thing, is that two of the key deficiencies would be so easy to fix. > The ability to reverse engineer the plaintext passwords from a workgroup file, is due to a simple error in how they encrypt the passwords. This could be fixed by reversing two parameters; ie. (probably) a 2-line change to the Jet source code. > The ability to instantly decrypt an encrypted database, could be fixed by the simple expedient of deriving the RC4 key from the database password. There would be no change to the Jet file structure, at all. Those two changes are so straightforward, IMHO, that I may even develop a product which does them!
If ULS is removed from Access then I would no longer have a use for the product at my place of work and everything I have developed so far would be migrated to Oracle. I don't have an option to use an SQL BE because to do so would be against our company's IT policy. In a nutshell, no ULS, no customer.
I don't know if I missed someone else making this point, but JET stands for "Joint Engine Technology". Do I get points for knowing that? I still use macros sometimes - they are quick to create and easy to read and maintain - but I wouldn't miss them if they were gone.
ULS is pretty much a waste of time for security because we even have MVP's like Jeff Conrad and Tony Toews posting cracks. However, it still has a use for marginal security and/or to differentiate users, which is a functional more than a security advantage. Overall, I would vote that ULS be retained, and some improvement to the password cracking be made along the lines suggested by TC.
Keith wrote:
> If ULS is removed from Access then ... everything I have
> developed so far would be migrated to Oracle. I don't
> have an option to use an SQL BE because to do so would be
> against our company's IT policy. Not sure I understand that. Do you actually mean, an "SQL*Server" BE? If so, you could link to an Oracle BE just as easily as an SQL*Server one.
Access works great as a frontend to SQL but it can be considerably enhanced. I, for one, am concerned about the lack of discussion (up to this point) regarding ADP enhancements. Perhaps you'll devote a little time to that subject in a future post. I regularly have discussions with myself about moving our development from Access to .net since SQL Server is our data storage choice. The ease of development and built-in user-friendly tools in Access keep me here but I would really like to hear that Access is continuing to develop as a better front-end app for SQL. Thanks.
I totally agree with Bill Holt. ADPs are absolutely critical for Access/SQL Server users. We long ago left MDBs because of the trivial ease of cracking the security model, and to take advantage of OLE-DB. I don't really use MDBs much anymore, but I am very worried about the future of the ADP. On another security note, the VBA code passwords are also a joke - it takes a millisecond to crack with freeware available on the Internet. Please give us secure VBA passwords, and VBA project encryption.
TC - Oracle is a full system - it does not have to rely on Access or any other Front End, unlike SQL Server. I understood Keith to mean it may be worthwhile getting out of the scenario of unsecure front ends entirely.
Regards
Looks like from some of the responses here that there are several distinct streams that Access is being used for (the percentage of its use cannot and should not however, be gauged on the one vocal response as it cannot represent the large number of Access apps created by programmers and non programmers). Access JET .mdb is a very mature technology. It is very understood by senior developers since it is at least 10 years old. I would expect not to "chuck it out" considering that there is a continuing revenue source from it's support. By "chuck it out" meaning to stop adding features to it or making new Access features inoperative if you select it. The ULS has always been problematical because it is onerous to administer but it has one facet - it allows us to simply differentiate users (user login) and differentiate between the developer vs the user (them and us) in terms of object permissions and design. Of course, third party could re-invent the whole thing if ULS disappears but breaking it does not make sense. Access + SQL Server looks like gaining some ground - this despite the fact that Jet cannot insulate the event handling and the performance impacts. And that .ADP is such a weap wrapper over SQL-DMO and OLEDB. And that Access is not a three tier animal supporting business objects and class abstraction. Access + Sharepoint which Eric assures us is growing waay fast - (as fast as the number of Access Team Members in Microsoft?). I may not doubt the growth rate, but I doubt the quantum compared to the previous two architectures. So, where is Access headed? And will we get a better beast which can is multi-faceted or will we get an beast which is all features and no substance?
Comments: (loading) Collapse