写于20210906。
起源在于我想要整理一下自己一团乱麻的密码，想要找个合适的方法记录密码。人脑毕竟是有极限的，遗忘也是难免的。然后考虑到最简单的word自带的加密以及rar加密。主要是保存密码，除了考虑安全性，也需要考虑是否方便，不然有些密码一找不到就直接重置了，似乎保存密码也没有了意义。最简单的，我们需要一个加密后的文件，可以放在电脑或者手机，点开输入密码后可以直接看到。再不济，重要账号的密码，可以自己添加一个简单好记但只有自己知道的密码转换规则，只将加密后的密文保存在加密后的文件中。
所以我的想法仅仅是证明一下这两个加密方法暂时还算可靠罢了。
最终觉得，没有完全严谨的无法破解的密码……但是加密算法加密流程的优化，使得破解的门槛及成本不断上升，或许在看不见的地方还有人在斗法，不过大部分人小小的隐私似乎也还无法引起那部分人的注意。而提供加密产品的人，也比我们更懂得如何保证加密产品的可靠性——如果他们并没有别的要求与心思的话。
1、word加密
1.0 总结
使用的版本是2019。
破解的方法或许有。但是已经出现的问题，word背后的团队应该会寻求解决的方法，所以我在网上找到的方法均已失败告终。唯一还没有尝试的持保留意见的是暴力枚举。一般来说，很多密码的最基础以及最终的破解方法都是暴力枚举，所以足够长且不定长，足够多的字符组合（大小写字母、数字、特殊字符），以及多次尝试错误后的保护机制：直接锁定、冷却时间、加入防止机器破解的图形码等等方法都是防止暴力枚举不错的方法。到了一定程度，暴力枚举虽然也是一种解决方法，但是所耗费的时间与复杂程度将不能被接受，还不如去研究加密方式中哪个地方有漏洞。
所以说，有些东西的优化，在我们看不到的地方，的确起了许多关键的作用。
1.1 加密方法
版本是2019，方法是【文件】--【信息】--【保护文档】--【用密码进行加密】，输入密码后进行保存，再打开就需要输密码了。
解除密码则是在输入密码的界面将密码删掉后保存即可。
1.2 解密方法1
参考：
是针对2010版本的word。我之前还在奇怪，但是后面认真看了看，我似乎误解了这个教程所面对的方法。这个方法所做的似乎只是将【密码限制编辑】的文档更改为可编辑。不然的话这个加密方法将会让人觉得很是简陋。因为一个这个是否加密仅仅是靠着一个明文的参数为1或者0来控制。
而解密的方法仅仅是使用文本打开后，查找到对应参数enforcement，更改其值而已。
而这个方法前面还有一步，就是打开文档后零存在xml文件。这部分就是我本来想要提的，但是既然这个教程仅仅是针对【限制编辑】的文档，那么这个还是留到后面来说。
1.3 解密方法2
参考：
写于2018年，针对的是2017版本的word。其中的
-
方法一：打开后-另存为xml-找到protection对应的部分删除部分代码--转回doc文档即可。
-
方法二：通过word本身的【插入】-【对象】-【文件中的文字】绕开加密。
-
方法三：通过Adobe Acrobat DC文件转pdf、pdf转回word的方法绕开加密。
我自己本身是没有实践成功的，也不清楚其可行性。针对这些方法，需要讨论以下几点：
-
密码不正确，还是能打开文件界面--一个未显示文字的错误的但仍属于该文件的操作界面。
-
word本身其他功能对于加密上的漏洞
-
给其他软件功能支撑上加密的漏洞
看情况，这个加密加了个寂寞，文档还是按照原本编码方式存在（未经加密转换），只是添加了一段代码，在程序识别到这段代码，那么应用会在加载文件的时候显示错误，仅仅未将文件内容加载到主界面。那么我删除这段用于识别的代码、或者由于某些功能未添加对这个拦路的“门”的识别，那么我就能直接读取到加密前的数据了。
不过2019版本的word文档，已经不一样了。
一是，密码错误完全不能打开文档，并没有另存为的界面，从另一个文档引用该文件也会提示需要输入密码。
二是，我将加密前doc文件另存为xml，然后用密码打开doc加密后的文件后另存为xml，对比两个文件的差别。
未加密的doc文件中可以很清楚地看到许多文档信息。如w:body/w:body所包裹的正文部分
<w:body><w:p w14:paraId="74F636FB" w14:textId="23CD0A65" w:rsidR="00F16D10" w:rsidRDefault="0078136F"><w:r><w:rPr><w:rFonts w:hint="eastAsia"/></w:rPr><w:t>大傻子！！！</w:t></w:r></w:p><w:sectPr w:rsidR="00F16D10"><w:pgSz w:w="11906" w:h="16838"/><w:pgMar w:top="1440" w:right="1800" w:bottom="1440" w:left="1800" w:header="851" w:footer="992" w:gutter="0"/><w:cols w:space="425"/><w:docGrid w:type="lines" w:linePitch="312"/></w:sectPr></w:body>
而加密后的doc文件对应的xml则是在使用文本查看的时候是乱码的文字，间或漏出一两个有点眼熟的英文，如下所示，其前面都是诸如NUL``EOT的格式，其后面大部分是中文及特殊字符乱码。在文件末尾有</encryption>
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <encryption xmlns="http://schemas.microsoft.com/office/2006/encryption" xmlns:p="http://schemas.microsoft.com/office/2006/keyEncryptor/password" xmlns:c="http://schemas.microsoft.com/office/2006/keyEncryptor/certificate"><keyData saltSize="16" blockSize="16" keyBits="256" hashSize="64" cipherAlgorithm="AES" cipherChaining="ChainingModeCBC" hashAlgorithm="SHA512" saltValue= ...... <dataIntegrity encryptedHmacKey="U7lJ/rC15dgyQ0u/O3qWjBs8t1IhEFm+N+OU83qrPOt//YK4SKcfe3Ej+hNxZDjNfePFRe5ga+pwwhGsbekwhA==" encryptedHmacValue="qV5rlXdI5bARCrNr47k8ofEIqRbnZ43aK1N/zRX+/raMKwBfqOcwH3tkPt7ASdh8ZD1SW4I/GcEaplWf+Ke+aQ=="/><keyEncryptors><keyEncryptor uri="http://schemas.microsoft.com/office/2006/keyEncryptor/password"><p:encryptedKey spinCount="100000" saltSize="16" blockSize="16" keyBits="256" hashSize="64" cipherAlgorithm="AES" cipherChaining="ChainingModeCBC" hashAlgorithm="SHA512" saltValue="ueu5rlVFNOHeUARbwkcHpQ==" encryptedVerifierHashInput="Z7vPrPk4zadDPpSjdHtEeg==" encryptedVerifierHashValue="nt0dv6PhWQP9oWbECsvBv7+9jLgjKuXo5z1qY081+xJVym6Scp7OnXvzArv5O98nmN8T0jlwwcgJQiO3DcpxXg==" encryptedKeyValue="czxp4ETtrmrtGi9mcZejP0CbIi9Priro4g+TyKTwhS4="/></keyEncryptor></keyEncryptors></encryption>
尝试分析一下加密后的文档，首先直接删除<encryption></encryption>里面的内容行不行？应当不行，看文件内容，这部分应该是包含了大部分加密后的文档信息。而且一个很重要的安全策略就是“不要尝试打开一个不完整的文档”。譬如说一个文档缺失了重要的基本文档结构信息，不会说使用默认的兼容的方式打开，加载能加载的信息，而是直接提示“Word 无法读取此文档，文档可能已损坏”。
那么根据能看懂的部分代码，是否能分析出加密方法，通过更改部分代码来“替换密码”呢？自我感觉不是很简单的一件事情，或者说需要去了解更多的底层知识。譬如说，如果encryptedKeyValue是最终的秘钥，前面提示了“SHA512”“AES”等等信息……通过观察多几个加密前后的文档的情况，来观察相同密码，不同密码，相同时间戳，不同时间戳等等情况下反推加密过程，通过得到的秘钥加密的过程，将自己最后的密码如“123456”进行加密后替换，那么最终就可以使用123456来打开加密文档了。
不过一切都是纸上谈兵罢了，加密算法的不断优化，在加大了加密流程耗费的时间与资源的同时也大大地加大了反向逆推解密的成本和精力。安全性大概还是可信的。
1.4 解密方法3
参考：
通过更改doc文件为rar文件后再通过打开rar文件的方式，读取到doc文档对应的一些详细设置的文档，如，比较关键的settings.xml文件，依旧是更改一下settings.xml文件中有关加密的那部分代码后破解。
现在不用想了，实践后，现在rar读取的时候会直接提示“rar文件损坏，无法打开”。
这种通过rar解包的方式让我想到了jar包。jar包中会包含对应的.class文件，以及.xml等文件，在抛去.class文件的一些反编译及防止反编译的讨论，如果我们将一些重要配置如数据库的账号密码直接放到.xml等类似的配置文件中，那么这些信息可以直观地看到，当然，也方便修改，所以在设计模式中建议可以将这些参数写在配置文件中。但是如果是一些对安全性有要求的应用……这样子做却是不怎么合适。
2、压缩包加密
2.1 加密方法
右键-添加压缩文件-然后如图所示，可以设置密码。可以加密文件、甚至加密文件名。是否勾选“加密文件名”的区别是：若是勾选了，那么打开压缩包就需要输入密码了，若没有勾选，可以正常打开压缩包，仅在打开对应文件的时候需要输入密码。
加密压缩后，原文件还在原来位置，需要删除。
解除加密密方法就是解压文件（输入密码）。
2.2 解密方法
参考：
这个就没有多少人列举解密方法，通常只能是枚举法伺候，有不少软件，word也有一些破解软件，大多用的枚举，我就都略过了，并不想下载奇奇怪怪的软件或者付费软件。
3、暴力破解和枚举破解
我之前称呼的是“暴力枚举”，因为我一直将这两种方法视为一种，后面仔细看了看还是有区别的。
暴力破解就是每一种组合我都试一试，进行排列组合，只要密码的长度和组合限制得足够，能跑到天荒地老。这种无差别的尝试，会把所有情况都考虑到，但同时也会做许多无用功。
而枚举，则是在有限的枚举库里面，将库里面的组合一一比对寻找。这样子耗费的时间是有限的，但是也有可能找不到密码。不过只要库足够好，找到密码的可能性不低，因为除非是随机生成的乱码，人为设置的密码，有时候还为了好记，总会有自己的特征。譬如说有些小傻瓜屡教不改使用123456做密码（指自己）。不要以为简单的密码没有人用，账号那么多，总有时候有人会觉得某个小号不重要，随意设置密码（再次指自己）。
4、密码设置的一些建议
虽说现在有时候觉得信息安全在这个时代有点像笑话，不过设置密码的时候需要注意一些事情，这些都是老生常谈了。
-
尽量不要多个平台公用密码，很容易某个平台安全措施不够就直接牵连全部了。甚至来说相似密码、一套的密码，如果真有人想搞你，弄个枚举库不是太麻烦的事情。
-
你心里觉得再不重要的账号，在随意设置密码的时候想清楚这个账号涉及现实的你的哪些信息，小心这些账号成为攻击你其他账号的跳板。在输入重要信息的时候，心里也想一想这个账号的密码是否有问题，是否够安全。
参考
如何记住各种账号密码？ - 首席鉴黄官的回答 - 知乎 https://www.zhihu.com/question/27259239/answer/781665625