Xls pwd (Recover passwords from Excel Sheet Protection) - Versionsgeschichte

Codecivil: /* Why publish code to recover passwords? */

2019-01-06T14:03:11Z

Why publish code to recover passwords?

Codecivil: /* How does the protection work? */

2019-01-06T13:58:58Z

How does the protection work?

Codecivil: /* How does the protection work? */

2019-01-06T13:52:33Z

How does the protection work?

Codecivil: /* How fast can we recover passwords? */

2019-01-06T13:49:59Z

How fast can we recover passwords?

Codecivil am 6. Januar 2019 um 13:46 Uhr

2019-01-06T13:46:28Z

Codecivil: /* How fast can we recover passwords? */

2019-01-06T13:42:01Z

How fast can we recover passwords?

Codecivil: /* Why publish code to recover passwords? */

2019-01-06T13:39:39Z

Why publish code to recover passwords?

Codecivil: Reasons for publishing the code

2019-01-06T13:26:39Z

Reasons for publishing the code

Codecivil: Reasons for publishing the code

2019-01-06T13:24:13Z

Reasons for publishing the code

Codecivil: Introduction and description of the weak points

2019-01-04T17:40:09Z

Introduction and description of the weak points

Neue Seite

If you protect your Excel Sheet (or, in the same fashion, an Open Document Sheet) with a password from cell modifications, you might be aware that this is just a protection from incidental changes. If the user of this file wants to change it, he can do so easily by removing the "sheet protection" tag from the worksheet XML files inside an archive manager. Detailed manuals for this are abundant on the internet.

Apart from making the file accessible you might also be interested in the password the creator of the file chose. In this note we want to provide code for recovering the actual passwords for the removal of the protection inside Excel (or LibreOffice Calc).

=How does the protection work?=
There is a clear and concise description of the "algorithm" on http://chicago.sourceforge.net/devel/docs/excel/encrypt.html, written in 2001. The scheme XORs and shifts the ASCII character bytes with the password length and a certain constant leading to a two byte hash which is the stored in the XLS file. Of course, there is such a great loss of information from the initial password that the set of shortest passwords matching a given hash is usually in the billions. It is a matter of a blink to find a suitable password, but this is not really a security issue since the file can be made available even easier anyway. The question is how Microsoft protects the intended password of the creator of the file from being identified. The creator, being unaware of the weakness of the algorithm, might have reused the same password elsewhere so there is a privacy matter. By the way, if you protect a sheet in an ODS file, a proper hash function is used and the information loss as well as the recovery speed are strongly reduced and a brute force attack seems is not viable.

=How fast can we recover passwords?=
It seems that Microsoft took the point of view that hiding a tree in a wood might be the best way to do that. Since there are billions of working passwords how can you recover them and identify the intended one? Well, the recovery problem is easy to solve. The operations of the algorithm, XOR and left shift, are very fast bitwise operations, and so are the reversals XOR and right shift. So you can recover at a rate of passwords per second which is in the percent order of the CPU frequency. The most limiting factor is writing the results to disk. In practice, an old laptop can recover and write to disk half a million passwords per second. So you are done with a full set after about an hour. Micrsoft probably chose such fast operations twenty years ago in order not to slow down the user experience any further when un-/protecting a sheet. The second problem, how to identify the intended one, is more of a psychological problem. But running a dictionary check on the passwords file might be a good idea.

=So why did MS never change the algorithm?=
Don't ask me.

@@ Zeile 17: / Zeile 17: @@
 =Why publish code to recover passwords?=
-This is for demonstration purposes only. The code works only for passwords with at most eight characters. The chance to recover a password as intended this way is very slim if the creator followed basic modern guidelines for the choice. Nevertheless, the code shows how fast and easy the hash reversal works and hopefully stimulates users to use more secure products or MS to change the hash algorithm.
+This is for demonstration purposes only. The code works only for passwords with at most eight characters. The chance to recover a password as the intended one this way is very slim if the creator followed basic modern guidelines for the choice. Nevertheless, the code shows how fast and easy the hash reversal works and hopefully stimulates users to use more secure products or MS to change the hash algorithm.
 =What about responsible disclosure?=

@@ Zeile 6: / Zeile 6: @@
 '''Do not use any valuable password for protecting Excel sheets!''' A password is valuable if you use it (or a similar one) also for other, more sensitive purposes. Or if the password itself would contain personal information. Well, both cases should not occur. If you have reused such a password you should change the ones for the sensitive purposes.
-=How does the protection work?=
+=What is the problem?=
-There is a clear and concise description of the "algorithm" on http://chicago.sourceforge.net/devel/docs/excel/encrypt.html, written in 2001. The scheme XORs and shifts the ASCII character bytes with the password length and a certain constant leading to a two byte hash which is the stored in the XLS file. Of course, there is such a great loss of information from the initial password that the set of shortest passwords matching a given hash is usually in the billions. It is a matter of a blink to find a suitable password, but this is not really a security issue since the file can be made available even easier anyway. The question is how Microsoft protects the intended password of the creator of the file from being identified. The creator, being unaware of the weakness of the algorithm, might have reused the same password elsewhere so there is a privacy matter. By the way, if you protect a sheet in an ODS file in LibreOffice, a proper hash function is used and a brute force attack with off-the-shelf equipment seems not to be viable.
+There is a clear and concise description of the "algorithm" on http://chicago.sourceforge.net/devel/docs/excel/encrypt.html, written in 2001. The scheme XORs and shifts the ASCII character bytes with the password length and a certain constant leading to a two byte hash which is the stored in the XLS file. Of course, there is such a great loss of information from the initial password that the set of shortest passwords matching a given hash is usually in the billions. It is a matter of a blink to find a suitable password, but this is not really a security issue since the file can be made available even easier anyway. The question is how Microsoft protects the intended password of the creator of the file from being identified. The creator, being unaware of the weakness of the algorithm, might have reused the same password elsewhere so there is a privacy matter. If the attacker has the opportunity to attack these more senstive data by brute-forcing billions of passwords, an a priori identification of the intended password ist not even necessary.
 =How fast can we recover passwords?=

@@ Zeile 7: / Zeile 7: @@
 =How does the protection work?=
-There is a clear and concise description of the "algorithm" on http://chicago.sourceforge.net/devel/docs/excel/encrypt.html, written in 2001. The scheme XORs and shifts the ASCII character bytes with the password length and a certain constant leading to a two byte hash which is the stored in the XLS file. Of course, there is such a great loss of information from the initial password that the set of shortest passwords matching a given hash is usually in the billions. It is a matter of a blink to find a suitable password, but this is not really a security issue since the file can be made available even easier anyway. The question is how Microsoft protects the intended password of the creator of the file from being identified. The creator, being unaware of the weakness of the algorithm, might have reused the same password elsewhere so there is a privacy matter. By the way, if you protect a sheet in an ODS file, a proper hash function is used and a brute force attack with off-the-shelf equipment seems not to be viable.
+There is a clear and concise description of the "algorithm" on http://chicago.sourceforge.net/devel/docs/excel/encrypt.html, written in 2001. The scheme XORs and shifts the ASCII character bytes with the password length and a certain constant leading to a two byte hash which is the stored in the XLS file. Of course, there is such a great loss of information from the initial password that the set of shortest passwords matching a given hash is usually in the billions. It is a matter of a blink to find a suitable password, but this is not really a security issue since the file can be made available even easier anyway. The question is how Microsoft protects the intended password of the creator of the file from being identified. The creator, being unaware of the weakness of the algorithm, might have reused the same password elsewhere so there is a privacy matter. By the way, if you protect a sheet in an ODS file in LibreOffice, a proper hash function is used and a brute force attack with off-the-shelf equipment seems not to be viable.
 =How fast can we recover passwords?=

@@ Zeile 10: / Zeile 10: @@
 =How fast can we recover passwords?=
-It seems that Microsoft took the point of view that hiding a tree in a wood might be the best way to do that. Since there are billions of working passwords how can you recover them and identify the intended one? Well, the recovery problem is easy to solve. The operations of the algorithm, XOR and left shift, are very fast bitwise operations, and so are the reversals XOR and right shift. So you can recover at a rate of passwords per second which is in the percent order of the CPU frequency. The most limiting factor is writing the results to disk. In practice, an old laptop can recover and write to disk half a million passwords per second. So you are done with a full set of shortest passwords after about an hour or a a day, depending on the password size. Microsoft probably chose such fast operations twenty years ago in order not to slow down the user experience any further when un-/protecting a sheet. The second problem, how to identify the intended one, is more of a psychological and statistical problem. Since this page is only about alerting on the issue, we do not go into detail here but surely this problem can be solved under certain conditions and circumstances.
+It seems that Microsoft took the point of view that hiding a tree in a wood might be the best way to do that. Admittedly, this kind of works if the intended password is long and random enough. Since there are billions of working passwords how can you recover them and identify the intended one? Well, the recovery problem is easy to solve. The operations of the algorithm, XOR and left shift, are very fast bitwise operations, and so are the reversals XOR and right shift. So you can recover at a rate of passwords per second which is in the percent order of the CPU frequency. The most limiting factor is writing the results to disk. In practice, an old laptop can recover and write to disk half a million passwords per second. So you are done with a full set of shortest passwords after about an hour or a a day, depending on the password size. Microsoft probably chose such fast operations twenty years ago in order not to slow down the user experience any further when un-/protecting a sheet. The second problem, how to identify the intended one, is more of a psychological and statistical problem. Since this page is only about alerting on the issue, we do not go into detail here but surely this problem can be solved under certain conditions and circumstances.
 =So why did MS never change the algorithm?=

@@ Zeile 1: / Zeile 1: @@
 If you protect your Excel Sheet (or, in the same fashion, an Open Document Sheet) with a password from cell modifications, you might be aware that this is just a protection from incidental changes. If the user of this file wants to change it, he can do so easily by removing the "sheet protection" tag from the worksheet XML files inside an archive manager. Detailed manuals for this are abundant on the internet.
-Apart from making the file accessible you might also be interested in the password the creator of the file chose. In this note code is provided for recovering the actual passwords for the removal of the protection inside Excel (or LibreOffice Calc).
+Apart from making the file accessible one might also be interested in the password the creator of the file chose. In this note we demonstrate that recovering the actual passwords for the removal of the protection inside Excel (or LibreOffice Calc) is almost as easy as removing the password. Code for this purpose is provided.
 =TL;DR=

@@ Zeile 15: / Zeile 15: @@
 Don't ask me. Ask MS.
-=Why do we publish code to recover passwords?=
+=Why publish code to recover passwords?=
 This is for demonstration purposes only. The code works only for passwords with at most eight characters. The chance to recover an intended password this way is very slim. Nevertheless, the code shows how fast and easy the hash reversal works and hopefully stimulates users to use more secure products or MS to change the hash algorithm.