I have noticed that password protecting a workbook and/or a worksheet from within VBA runs over  two thousand times slower in Excel 2013 than it does it Excel 2010.

Consider this simple code snippet

Sub Test()
    Dim i As Integer, max As Integer, tStart As Single
    max = 100
    tStart = Timer
    For i = 1 To max
        ActiveWorkbook.Worksheets(1).Protect Password:="pword"
        ActiveWorkbook.Protect Password:="pword"
        ActiveWorkbook.Unprotect Password:="pword"
        ActiveWorkbook.Worksheets(1).Unprotect Password:="pword"
    Next
    Debug.Print max & " iterations took " & Timer - tStart & " seconds."
End Sub

This takes 142 seconds in Excel 2013 and 0.06 seconds on the same computer using Excel 2010.

The same code without the passwords takes just 0.15 seconds in Excel 2013 and 0.05 seconds in Excel 2010. A factor of 3.

I am using Excel 2013 version 15.0.4420.1017 which as far as I can tell is the most up to date.

Has anyone else experienced this type of performance issue and found a fix for it?

Thanks in advance

Rob

Basically what's going on is that people suck as suggesting good passwords, and consequently an attacker will usually be able to guess your password for a file within a couple of billion guesses for good passwords and a couple of million for less good ones.

For an attacker, the length of time each guess takes is now really important. Whereas a user spends most of his time using Excel, an attacker spends most of his time trying to decrypt the first block of your file to see if it's been decrypted. This means that upping the length of time to derive a key from a password has a disproportionately negative effect on an attacker compared with on a user.

For example, if Microsoft choose a key derivation algorithm that takes, say, half a second (up from a millionth of a second) to turn a password attempt into a key to test, then the startup time for Excel goes from say 10 seconds to 10.5 seconds - an overall trivial inconvienience to the user.

Now let's say that your password is good enough that it takes 10 billion guesses (say a seven letter "good" password). It used to take an attacker 2 and a half minutes to brute force to get in; it now takes 158 years.

Effectively what you're seeing is this is practice. Microsoft is upping the strength of the key derivation algorithm to help protect your file from having the password brute forced by attackers.

What's perhaps slightly less obvious from your example, is that this has been happening since Excel 2003. Each revision ups the key derevation complexity in order to "catch up" with technology making longer lengths more acceptable to users (who have better hardware) whilst still keeping brute force out of reach of attackers, who also have markedly better hardware than when previous versions of Excel were released.

@ZippyV "Doesn't make sense" Perhaps not in the isolated example, that was just to illustrate the performance issue. I thought I'd keep the post simple so people could understand it

I agree with @evildictator but they've really messed up on this one. I have found other people moaning about this but no resolution as yet.

Anyway, I have had a direct response from Microsoft to say they are aware of this issue and are currently researching the problem.

I guess you just to have unprotect all before the entire code is ran and protect afterward instead of doing it per method call because I think that's more likely what you were doing.

1 day ago, robwellis wrote

I agree with @evildictator but they've really messed up on this one. I have found other people moaning about this but no resolution as yet.

Sadly this one's going to come back as a "won't fix" from the team. This behaviour is by design.

A better question is why your program needs to act in this way (other than for the obvious reason that it did it that way before).

1. Do your workbooks really need to be protected (given that you're unprotecting them anyway, which kind of makes the protection redundant).

2. Do you need to unprotect the workbook to use it?

3. Are you doing the processing on the user's machine? If so, consider offloading the work onto servers. If not, consider upgrading the servers to cope with the load.

4. You will probably find that parallelising the work makes a big difference, and that the cheapest method of parallelism is to run your program N times simultaneously. Each program can pick a file out of the "encrypted files" folder, move it to the "in use" folder and then unprotect, work and reprotect the file. It can then move the final file to the "done" folder. Now run the program 40 times and leave them running and you'll very quickly chew through the files.

MS: It's a shame.

The performance on Excel 2013 is very very very poor.

I'm glad to keep Excel 2010 in my machine.

I'm fell like a moron to bought MS Office 2013.

MS is doing a good job to get out of market.

I have a lot of excel files with macros and the macros run very slowly (compared with MS Excel 2010).

Even a simple task of put a new number in a cell is slow process (after press enter of course).

When we bought a soft we couldn't think that the performance will be worst than the older.

9 minutes ago, ErwinHeisler wrote

When we bought a soft we couldn't think that the performance will be worst than the older.

Really? Sounds like you need to read this then:

http://en.wikipedia.org/wiki/Wirth's_law 

So I guess I have to maintain my:

Intel i7-3960X CPU @ 3.30GHz, 16 GB RAM, SSD SATA 3 - 480GB.

and

use EXCEL 95 on it.

Luckily my Acrobat XI, AutoCAD 2012, Alibre 2012, ... performance better than the previous version.

25 minutes ago, ErwinHeisler wrote

Luckily my Acrobat XI, AutoCAD 2012, Alibre 2012, ... performance better than the previous version.

I might be inclined to believe you, except you list Adobe products and AutoCAD.

Software is a complex beast, and often "performance issues" aren't always the fault of the software or hardware, and are difficult to pin down.

I just did some test with Excel, and it's performing beautifully on my dual core gen2 i5, even though I'm running high memory and CPU utilization because of something else I'm running. As impressive as your machine may be, you've got something else going on.

57 minutes ago, ErwinHeisler wrote

@evildictaitor: Really...

So I guess I have to maintain my:

Intel i7-3960X CPU @ 3.30GHz, 16 GB RAM, SSD SATA 3 - 480GB.

and

use EXCEL 95 on it.

Luckily my Acrobat XI, AutoCAD 2012, Alibre 2012, ... performance better than the previous version.

Thankfully due to Moore's law your computer hardware gets enough faster in any given timeframe to cope with the fact that the software in that timeframe is getting slower (and this is why most people don't notice).

But the key thing here is that if you upgrade your software and never upgrade your hardware, after a while it's gonna get painful.

43 minutes ago, evildictait​or wrote

*snip*

Thankfully due to Moore's law your computer hardware gets enough faster in any given timeframe to cope with the fact that the software in that timeframe is getting slower (and this is why most people don't notice).

Moore's law is a poor excuse and IMO overly abused.

Edit: "Moore's law states: You're holding it wrong."

2 hours ago, DeathBy​VisualStudio wrote

Moore's law is a poor excuse and IMO overly abused.

Edit: "Moore's law states: You're holding it wrong."

Who uses it as an excuse?

It's unforgivable that MS release Excel with a lot of flaw in performance (it's a calculation program for a God sake).

Are the programmers relaxed about computers getting faster and didn't pay attention in theirs code?

Why we users should pay to get a inferior product? MS are losing focus. I'm sad because I used to love this company.

The fact that Excel uses strong key generation to secure your document when you click the "I would like to secure my Excel document with strong key generation" is not a performance issue. It's by design. In fact, if it were fast to open large numbers of password protected files, it would be fast to brute force passwords, and someone would log it as an Important bug at Microsoft and tell them to fix it.

If you're talking about some other performance defect in Excel, that's fine, but open a new thread to discuss it. This particular thread discusses slowness in opening password protected documents. This slow down is by design in order to keep your documents safe, and if you don't like it you can turn password protection off.

20 hours ago, ErwinHeisler wrote

(it's a calculation program for a God sake).

Actually it's not, and using it as such will lead to poor performance. It's spreadsheet software, primarily designed for simple handling and display tasks of business data. If you're doing heavy calculations you want to use something like this, this, this or this.

I work within a large British college and we have switched to Office 2013. My job is to create and maintain custom reports based within excel so I use VBA the majority of my working time.

Just about every single report I run has at least doubled in processing time since switching from 2010 to 2013. Only one has a similar macro as mentioned here to do with locking/unlocking sheets. The rest are simple data manipulation from imported documents (like loading in a raw data dump and producing a report from it) and they are all a lot slower too.

I can do the usual things such as hiding screen updates whilst running but again still a lot slower. Im on a decent spec computer and also tried on one of the top end i7 we have and still a ton slower.

Quite disappointed with 2013 really.

Office 2013 has silently introduced security changes in order to strengthen Excel protection. Excel 2013 uses a SHA-2 class SHA512 algorithm to calculate the hash values for the encryption keys, which cannot be cracked within a reasonable amount of time using the brute force methods applicable up to Excel 2010. 

Have you noticed that sheet protect / unprotect VBA methods run slightly slower in Excel 2013 ? - That's because the new complex encryption algorithm takes longer to compute.

It is impossible to find multiple passwords that share the same hash value in Excel 2013, as was the case with Excel up to 2010 version.

Please read:

www.spreadsheet1.com/sheet-protection-2013.html

My app (since 10 years..) lets a user compare two workbooks. In order to read all cell properties without errors I need the passwords of protected sheets. I'll also need the passwords if a user decides to "highlight" results.  My current approach is trying each supplied password (plus space ,x, xx and xxx ) on all worksheets, which is/was convenient. I'll find a different approach for xl15.

My app always works with form plus 2 windows..  the change from MDI to SDI was a nightmare involving a lot of "hooks/subclassing" to get it solved. This is just a minor hiccup. And in my experience xl2013 isn't all that slow except on the UI side: activating window/sheet/range requires up to 250ms until fully rendered.

I've learned a long time ago to avoid screenupdating (as in "select" and "activate") until the code is ready to return to the user. xl15 does a lot more on a simple selection: the "selection" box is animated and each window has a ribbon with a "few" callbacks. A lot happens on a simple window activate and it ain't all pretty.