Microsoft Windows / Office upgrade woes

[isladogs]

Microsoft's current upgrade model is in my opinion badly flawed.
Even their support staff are advising people not to upgrade and to block such upgrades as long as possible

The last two Windows 10 updates have both caused me significant problems.
The 1803 update caused issues with the geolocation service in IE.
I reported this as a bug with v1803 in May. MS released a fix in June but it didn't work. Reported it again that month. Still not fixed

So I uninstalled v1803 reverting to v1709 & blocked further updates for the maximum time available - approx 3 months I believe.
Unfortunately I was away when that period ended & returned to find it had reinstalled itself ... hello I'm back (with the same issues). Grrr!

So it seemed worth the risk to allow the 1809 update when it was offered almost immediately afterwards hoping it would fix various issues
Sadly not as version 1809 immediately caused the following issues for me
1. Virtual Box had to be removed to install the update. Afterwards I reinstalled it but it no longer works
2. My Comodo code signing certificate cannot be used so I can't code sign my software
3. Geolocation data service still fails in IE.

All of these seriously affect my ability to test and distribute Access applications.
I've just removed v1809 after only 2 days and will again be informing MS of the latest issues.
Have reverted to 1803. The code signing certificate works perfectly again but the other 2 issues remain.
I'm likely to do a fresh install and stop at v1709 if I can still do so.

Although I have Office 365 and test my apps in that, I still develop using Access 2010 by choice as it is stable and the interface is in my view much more user friendly

Having said that, Office updates have only rarely caused me grief (though I still remember the debacle of Access 2003 SP3 & its subsequent hotfix)
I use Office 365 purely for testing so I know whether my clients who use it will have issues with any application updates I release

Even so, updated features like the new charts have sadly been utterly useless to me.
The interface looks better but the chart types are more limited.
The deal breaker is that, if new charts are used, clients with earlier versions of Access will see nothing other than an empty space where the chart should be. The documentation makes no mention of that!

 

[RuralGuy]

I thought I recognized the dog.

 

[isladogs]

Hi Allan
Hope you are well. Haven't seen you on here for a while....
At least the dog is consistent. No plans to upgrade Isla

 

[RuralGuy]

Hi Colin. I'm on most every day, just don't post that often any more. Always enjoy your stuff!

 

[jdraw]

I'm having internet issues (3 days now). Technician to arrive soon this AM. I have a notice from M$oft that I require a system restart and it will install 1809. Don't want to do that because my speed is so bad I can't do a speed test, it fails on time. After Colin's experience, I'm not sure I want to do it regardless.

I did watch someone on youtube last Wed install 1809 on high end desktop ---still took about 30-40 minutes and that system had lightning speed internet and very fast PC.

Glad to see both you guys "up and at 'em" early in the morning.

 

[isladogs]

Hi Jack

Of course its mid afternoon here!

I'm getting nowhere trying to contact MS today
There are 4 options and for once it looked promising

The call back feature fails repeatedly ... An error occurred
Call back also failed
Talk to an agent never connects - waited 30 minutes whilst doing other things

I definitely would put off 1809 update but 1803 was dreadful as well

BTW I let v1809 install overnight so don't know how long it took - probably a couple of hours like v1803 did

 

[isladogs]

Hot off the press....
MS have pulled the 1809 update as of yesterday due to 'isolated problems with users losing files!!

https://answers.microsoft.com/en-us/windows/forum/all/windows-10-october-update-is-no-longer-being/62e8e6b4-0089-41c2-a104-5a5a768a48f6

Can't be that isolated if they've responded like that

 

[shadow9449]

(though I still remember the debacle of Access 2003 SP3 & its subsequent hotfix)

I know this is peripheral to your main point but what was the debacle of ACC2003 SP3 and the hotfix?

I still use Access 2003. I don't want to change topic here by elaborating on why, but in one sentence: I have yet to see anything compelling in subsequent versions. If you look at the Access User Voice that's been pretending to solicit input from users as to what THEY want, you'll see a lot of "bring back..." and "PLEASE fix this bug...." and so on. Based on your post about windows (and the experience from using Windows), it's not surprising that the opportunity to address everything that Access could be to bring it to the modern era has been bypassed to add very little and only time will tell what new bugs will be rolled out in the latest edition.

 

[Gasman]

I think I might have posted this before, but I have this in a .cmd file.
I run it at startup and every hour via Task Scheduler as MS had a habit of enabling it again.

Rem stop windows update
sc config "wuauserv" start= disabled
sc stop "wuauserv"
rem Pause

HTH

 

[isladogs]

Combo box controls and list box controls display no value or incorrect values in Access 2003 after you install Office 2003 Service Pack 3

See https://support.microsoft.com/en-gb/help/945674/description-of-the-access-2003-post-service-pack-3-hotfix-package-dece

So literally you would have blank controls!
The hotfix was released quite quickly because SP3 made many Access databases useless until they did so.
I'm sure you installed the hotfix many years ago!

BUT it goes to show that update screw-ups are nothing new.

However I would definitely recommend updating to e.g. Office 2010 as Office 2003 is no longer getting any security updates.
In any case, the ACCDB file format is much more secure than MDB
See http://www.mendipdatasystems.co.uk/compare-access-file-security/4594431226

 

[isladogs]

Gasman
Actually one relatively good feature in the 1803 update was the ability to postpone updates semi-permanently in Update Settings. See screenshot

Unfortunately you had to install 1803 to be able to do that

 

[shadow9449]

See https://support.microsoft.com/en-gb/help/945674/description-of-the-access-2003-post-service-pack-3-hotfix-package-dece

So literally you would have blank controls!
The hotfix was released quite quickly because SP3 made many Access databases useless until they did so.
I'm sure you installed the hotfix many years ago!

BUT it goes to show that update screw-ups are nothing new.

Absolutely. Many Microsoft releases, including the HUGELY vaunted revamp of Access in the 2007 version include ridiculous errors that could have been caught in 15 minutes of beta testing.

However I would definitely recommend updating to e.g. Office 2010 as Office 2003 is no longer getting any security updates.

I didn't want to change the track of the thread (unless no one objects) but I have to weigh the security updates against the fact that once converting my app, I would have to deploy it and change the shortcuts, startup scripts, linked tables and so on for literally several thousand computer across the country to accommodate the .ACCDB extension. In the vein of this thread, I actually happen to like that Microsoft will not be issuing any updates to my platform.

In any case, the ACCDB file format is much more secure than MDB
See http://www.mendipdatasystems.co.uk/compare-access-file-security/4594431226

I saw that and weak security in Access is one thing that Microsoft does not take seriously. The ULS was never a serious tool. The encryption, while more secure, as you pointed out, is not a serious tool either. It take Access security from "keeping honest users honest but not deterring slightly determined dishonest users out" to "keeping slightly less honest users honest but not deterring slightly more determined dishonest users with a hex-editor out". If Microsoft actually implemented HIPAA-grade security rather than saying "just go to SQL Server" then I'd be interested

Cheers

 

[isladogs]

The encryption, while more secure, as you pointed out, is not a serious tool either.

Hmm I'd disagree with that.
Password protection in MDB files provides almost no security at all. Only parts of the file are encrypted and even then with very weak encryption
By comparison, password protected encryption in ACCDB files is 128-bit and the entire file is encrypted.
I'm not saying its the best security there is but you'd need to know what you were doing and still work very hard indeed to break the code.

Taken from Stackoverlow

Jet 3: The database password, when set, is stored as plain text in the MDB file header.

Jet 4: The database password, when set, is obfuscated with a simple XOR pattern algorithm based on the file creation date/time (stored inside the file) which is then stored in the MDB file header.

Jet 3 AND 4: The MDB file header itself is further obfuscated with an XOR pattern – although its a constant XOR stream this time.

ACCDB Files: The password is no longer stored as obfuscated plain text in the file header. Instead, a hash is used to check that the user has entered the valid password. The hash is generated from a combination of RC4 and SHA-1 algorithms.

Whilst I'm not totally clear about what that all means, there are some excellent articles about Access security here: https://www.everythingaccess.com/tutorials.asp

Suggest you do start a separate thread about Access 2003

 

[Pat Hartman]

I made the mistake of contacting Microsoft Help (which is actually outsourced) when 1803 made my Office installation unusable and I wanted to roll back to the previous release. That was extremely costly since the people who "helped" me deleted all my Outlook contacts, calendars, and rules. I still am missing contacts from that debacle. Be very careful allowing these incompetents to do anything to your system!!!

 

[isladogs]

I may have hit lucky but I twice got excellent help from MS after my 1803 debacles back in May/June.

It looks like 1809 is an even bigger shambles now that MS have had to withdraw it after 3 days. Unfortunately too late for me.

What I want to know is if I do a fresh Windows install now, what version will it be? I do have install media on a USB stick dated Nov 2017 so that should be 1709. What I don't know is whether it will update to the latest version when it is run.

 

[The_Doc_Man]

Whilst I'm not totally clear about what that all means

I can try to explain.

Jet 3: The database password, when set, is stored as plain text in the MDB file header.

= Anyone with notepad can quickly find the password since the header is early in the file.

Jet 4: The database password, when set, is obfuscated with a simple XOR pattern algorithm based on the file creation date/time (stored inside the file) which is then stored in the MDB file header.

= Anybody with a hex editor can manually find two things: The binary file creation date & time and the password, and can figure out the password as long as they understand XOR. Both of those things are in the header so it wouldn't take long to find them.

Jet 3 AND 4: The MDB file header itself is further obfuscated with an XOR pattern – although its a constant XOR stream this time.

The file header's encryption is a simple XOR pattern. If you know other things that should be in the header and know them in clear text, you can probably work backwards or write a VERY simple algorithm to decrypt the header. Because the XOR pattern will even encrypt 0 - and in the process will give you the inverse of the XOR key.

ACCDB Files: The password is no longer stored as obfuscated plain text in the file header. Instead, a hash is used to check that the user has entered the valid password. The hash is generated from a combination of RC4 and SHA-1 algorithms.

The hash-checking algorithm is based on the same technology that gives you digital signatures. In essence, a signature is a polynomial (in binary, of course) based on some obscure formula that gives you a long string of bits by multiplying two numbers together in some orderly pattern. When you complete the multiplication you have a hash (which in math is sometimes called a "characteristic") that depends on the contents of the thing you were trying to sign. It doesn't matter whether the thing being protected is short or long. When you attach the hash value as part of the item you have signed the item in a way that is very difficult to spoof. If you send the hash in a separate signature file, your recipient can confirm your identity.

In general, if you have a 128 bit hash, that hash sequence has 2^128 possible values, which is roughly 512 * ( 10^36 ). So the odds of accidentally generating the same hash value from two different inputs SHOULD be 1 divided by that number, which is pretty small - something like 0.2 * ( 10^ -38 ).

There are ways to determine how big a file has to get before that probability gets big enough to even worry about. But the point is, if you store the HASH of something and then later input that something again, you can't compare the something - but you CAN compute the HASH of something and compare it to the stored hash. If the hashes match, the inputs probably also matched.

Now, the only other two things that might be confusing is that RC4 and SHA-1 are two popular hash-generating algorithms. Each is based on a different polynomial. So if you enter a password and BOTH of the resulting two hashes match the stored hashes, you are fairly sure that the right thing was entered. After that, the database decryption key can be generated from the password.

Why is this any better than simply obscuring the password? (You might ask?) Because the hash computation is one-way. It is irreversible. The fact that the hash is of a fixed length means that if an overflow occurs out of the high-order bit of the hash slot, bits get lost and without those lost bits, you have a very large number of possible solutions to the polynomial. Not QUITE infinite since the inputs had to be finite - but it is a REALLY BIG number of possible solutions.

However, just before I left the Navy, they were upgrading requirements to use the 192 bit or 256 bit versions of SHA-1 and the other hashing methods. As tough a nut as the SHA-1/128 was to crack, SHA-1/256 is a nightmare.

 

[RuralGuy]

Thanks once again Doc. The depth of your knowledge is astounding.

 

[The_Doc_Man]

You're welcome, Allan.

That's the sort of stuff I had to learn as a Navy sys admin on a machine that carried sensitive and HIPAA data. I also had to learn how to constructively use them. But since they didn't want me to be a hacker ("certified ethical" or otherwise), I never got that deep into the specific polynomials.

 

[isladogs]

Hi Doc

Actually I understood almost all of it before but your explanation was so clearly written that it filled in the gaps perfectly ...and with no obfuscation!
Well deserved RPs awarded to you.

As you may know, I wrote a lengthy article on Access file security at http://www.mendipdatasystems.co.uk/compare-access-file-security/4594431226 .
In that article, I gave several examples showing how a hex editor can be used to read the contents of both MDB and MDE files including those supposedly password protected.
I've done this for files created in Access 97 onwards. I also showed the results for ACCDB files

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

However, the one part of the original that still isn't clear to me is that, after describing each separately, the JET 3 and 4 section gives different info from that given earlier.
Can you explain the Jet 3 disparity as I have no JET 3 files available to look at (see request below)

Also a request to anyone who can help.
I would like to use a text editor to view an old JET 3 MDB file with a password that was created in Access 95 or earlier.
If anyone has something non confidential I can use, please could you zip and post it here or email it using the link in my signature line.

 

[shadow9449]

By comparison, password protected encryption in ACCDB files is 128-bit and the entire file is encrypted.
I'm not saying its the best security there is but you'd need to know what you were doing and still work very hard indeed to break the code.

Ok, so 2 (somewhat similar questions):

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

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

- If yes, then I will agree that this security opens whole new industries and uses for Access that could not be legally implemented in older versions.

- If not, then the protection that it offers means that we've upgraded the security from only locking out people who know very little about anything more than how to use the basic interface (which is probably the majority of users, to be honest) to locking out more determined and more technical baddies. The benefit of this is not substantial enough to redefine what Access can be used for IMO.