Microsoft Windows / Office upgrade woes (1 Viewer)

I don't know the legal requirements with regard to credit card info but I believe there has to be physical separation between client personal details and credit card info. In other words, never stored in the same database.

Similarly I wouldn't recommend storing user passwords in a database. Where clients state it has to be done, I encrypt that information using an RC4 cipher and then separately encrypt the entire datafile

With regard to both examples you gave I definitely wouldn't use Access for this information but not just for security reasons. SQL Server or similar will provide both additional security but also increased stability and scalability.

However, where Access is suitable in terms of stability and scalability, there is no question in my mind. Both MDB and MDE files are completely insecure. The passwords can be hacked easily and even without doing that, the files can be read using a text editor.

Encrypted ACCDB/ACCDE files are significantly more secure. Using a text editor reveals nothing. Passwords are very difficult to hack and can only be done using brute force. If a strong password is used that will take many hours and possibly more than a day. Will any hacker have access to the file for that long or think its worth the time and effort?

So if your data is in your opinion suited for storage in Access but contains anything remotely private/confidential, I would definitely advise converting to encrypted ACCDB/ACCDE or SQL Server

1. Is it advisable (or even legal) to store credit card information in an ecrypted ACCDB?

Click to expand...

In general, legality is a matter of jurisdiction in the USA. However, I would say that it is probably NOT advisable for a pure Access solution. If you had an Access FE and the encrypted stuff was in a back-end that provided some encryption, you might be OK. There IS such a thing as Encrypted SQLnet.

2. Is it acceptable in most jurisdictions to use encrypted ACCDBs for patient health records, which are privacy-protected by law?

Click to expand...

In the USA, the HIPAA records must be kept according to strict standards. I don't recall that you can make Access use 256-bit encryption and probably cannot choose which of the many encryption algorithms you will use. That would be a barrier. The government standard is going to be one of the block-chain ciphers (of which there are several) and will certainly be of the 256-bit variety. (Which for encryption is the length of the chosen encryption key.) So offhand, I'd say no to medical records, too.

isladogs said:

With your permission I would like to add your explanation to the article.

Click to expand...

Permission granted.

Can't help you much with the "old JET" stuff since I don't have anything going back that far any more. When my wife's previous computer went wheels-up in the ditch a couple of years ago (euphemism for a really ugly hard-drive crash), the last JET3 I had went with it and I had to upgrade the backup copy to the next nearest version of Access I had, which involved JET 4.

@Doc_Man and Colin:

So, I think we've had a good summary of the extent of the security improvements of Access 2010 over the old ULS. In short, it makes it far less likely for someone to hack sensitive data but still not secure enough to open up the medical industry or the ability to integrate with credit card processing to Access users. I think that going ALL the way would be nice...

Cheers

Hi shadow
Following my request a forum member kindly sent me what they thought was an Access 95 password protected split database. In fact it was an Access 2000 MDB file with ULS but no password.
It took me less than a minute to open the frontend and copy all database objects & code to a new unprotected database.

ULS is almost completely useless & MS were in my view wise to drop the feature for Access 2007.

You deliberately chose two examples where security issues probably make Access unsuitable. Fair enough!
Where that is needed or legally required, another database is more suitable

However, for the vast majority of databases, 256-bit encryption is unnecessary. The current 128-bit encryption is perfectly good enough for almost all databases.

Nevertheless you can use strong encryption on selected data if you need it e.g. user passwords. You MAY even be able to do that with old MDB files

isladogs said:

Hi shadow

You deliberately chose two examples where security issues probably make Access unsuitable. Fair enough!
Where that is needed or legally required, another database is more suitable

Click to expand...

Exactly. Because in the context of the discussion, this is the point I was making.

i.e. Microsoft DID enhance the security, but not enough to be a game changer. To me, a game changer would mean that I can use An Access/ACE solution for completely new industries that I could not before. It's a bit disappointing that if they are adding encryption anyway that they didn't bother making it HIPAA grade so Access developers have more of a market.

And I do think that if they would, it would be reason for me to migrate.

Makes sense?

I also recommend updating to 2010 - and maybe stopping there. Among other features, couple enhancements you might appreciate (I think both actually came in with 2007):

1. 50 rules available for Conditional Formatting

2. ControlSource property added to Image control

For info, I have updated and extended the article on my website comparing security in Access MDB/MDE with ACCDB/ACCDE files.

Additional information has been added regarding security features available in each version of Access. Many thanks to the Doc_Man for his detailed explanation re encoding/encryption in JET3/JET4/ACE. If you are interested, see:
http://www.mendipdatasystems.co.uk/compare-access-file-security/4594444323
http://www.mendipdatasystems.co.uk/access-security-by-version/4594444347

The only version I am currently unable to check fully is Access 2000 as I no longer have the 2000 CD.
If anyone is able to assist by providing me with an ISO file for Office 2000 Pro or Access 2000, I would be very grateful.