这是一个创建于 1529 天前的主题，其中的信息可能已经有所发展或是发生改变。
真事。
这个小程序是我大四的时候做的，用于记录自己的各种密码，但是数据只支持保存在本地。我媳妇也一直在用这个小程序，媳妇是做新媒体的，各种账号很多（应该保存了有四五十多个了），最近媳妇要换手机，但是数据没法迁移，因此直接推动了我重构了这个小程序。（当然我自己也一直有重构的想法，因为我自己也在用，且原来界面很丑！）
重构了之后支持云端存储数据。数据存储使用的是腾讯的云开发免费额度，有 2G，对于一个家庭来说完全足够了。数据加密方式支持使用 AES 和国密 SM4，加密密钥是主密码。
欢迎广大 V 友来体验哈！
小程序名称：账号助手。
小程序码：
第 1 条附言 · 2020-10-05 10:33:39 +08:00
看到评论上已经将这个话题带到“数据存在国内 /TX 安不安全上了，更有认为国内比国外安全...”，作为腾讯的常用用户，使用前肯定是信任的，毕竟我的一部分钱也放到微信上，这事情见仁见智吧
第 2 条附言 · 2020-10-05 20:00:34 +08:00
解析一下小程序的实现
第一， 小程序数据加解密密也是在微信客户端
第二，加密算法实现也是开源
sm4: https://github.com/wechat-miniprogram/sm-crypto/blob/master/src/sm4/index.js
aes: https://github.com/brix/crypto-js/blob/develop/src/aes.js
第三，其实我并不希望用户使用我的小程序，而是希望用户独立拥有一个自己的密码管理小程序
第四，小程序有免费云存储额度（两个环境各 2G ）（理论上可以存到腾讯倒闭）
第五，用户保存的数据受微信和云存储鉴权保护，数据传输采用的私有协议传输，理论上更安全
看了下评论区，总结一下这种密码管理方式不适用对象吧：
一、不信任国内服务商
二、不信任腾讯小程序云服务的安全性
三、认为国外服务商更安全
第一， 小程序数据加解密密也是在微信客户端
第二，加密算法实现也是开源
sm4: https://github.com/wechat-miniprogram/sm-crypto/blob/master/src/sm4/index.js
aes: https://github.com/brix/crypto-js/blob/develop/src/aes.js
第三，其实我并不希望用户使用我的小程序，而是希望用户独立拥有一个自己的密码管理小程序
第四，小程序有免费云存储额度（两个环境各 2G ）（理论上可以存到腾讯倒闭）
第五，用户保存的数据受微信和云存储鉴权保护，数据传输采用的私有协议传输，理论上更安全
看了下评论区，总结一下这种密码管理方式不适用对象吧：
一、不信任国内服务商
二、不信任腾讯小程序云服务的安全性
三、认为国外服务商更安全
 |
101
KyonLi 2020-10-05 23:28:42 +08:00 via iPhone
telegram 观光来的，味很冲
|
 |
102
wevsty 2020-10-05 23:35:20 +08:00  1
@v2lhr
1 、开源是信任的基础，没有这个基础就不存在任何信任。没有信任确大谈安全是无意义的。 2 、我指的是密码管理器可以为被管理密码的网站的两步验证提供支持。 （比如 Apple 的两步验证，需要输入的那个 6 位按照时间变动的验证码） 3 、KeePass 的抗穷举是以拿到加密后数据为前提的。 抗穷举的实质是加大穷举出正确密钥的难度，KeePass 使用了 AES-KDF 或者 Argon2 来提高穷举密码的代价以降低穷举速度。 简单的说直线思维上： AES( 密码 , 加密数据 ) = 结果 而使用 AES-KDF 会变成 AES( AES-KDF( 盐, 密码, 迭代次数 ) , 加密数据 ) = 结果 由于 KDF 的运算代价，在固定的硬件上可能需要近似的时间才能确定密钥是否正确，如果迭代的次数足够多那么你确定密钥正确的速度就会非常慢。 最终从效果来说，可能同一台机器上使用了 KDF 只能做到每秒穷举 1 个密码，而不带 KDF 则可以每秒穷举成千上万个密码。 4 、对于小程序，微信实质上就是操作系统。 如果对我 Windows 不放心，我还可以选择 MacOS，对 MacOS 不放心我还可以选择 Linux 等等等，而用你这个小程序，从头到尾都只能选择微信。 另外还有信任链的问题，信任链越长对信任的难度就越高。 要信任你的小程序需要同时信任底层的操作系统+微信，如果你不信任 Windows，那么在 Windows 上运行的微信同样也没有信任的基础。 5-6 、这些问题是一开始你就应该说明的，也许说明清楚有些人的看法会有所不同。 |
 |
103
20015jjw 2020-10-06 00:16:40 +08:00 via Android
lol 信任腾讯
|
 |
106
jimmy3780 2020-10-07 01:22:45 +08:00 2
|
 |
108
msg7086 2020-10-07 06:32:50 +08:00 2
分享自己的经验、设计和代码，是件好事。
但是楼主对密码相关系统的了解还停留在比较基础的阶段。 比如说上面提到的抗穷举算法不知道，这就是个很大的坑。 大部分人都不是密码学专家，所以设计出来的密码学工具很可能会分分钟被人破解，造成重大损失。 你媳妇看到你发的贴被人回复成这样感到愤怒。那么当她把网银密码存在小程序里结果被人脱了库，家里的储蓄都被人转走了，她会不会感到愤怒呢？回复里提出的很多观点都是有其道理的。 不瞒你说，我也不是密码学专家，所以我绝不自己做密码学工具。 如果我需要这样的一个产品，我会去找 (1) 专业公司发布的工具，或者 (2) 经过专业人员审计过的开源工具。 不管怎么样，感谢分享，但同时警告，不要对非专业人员设计的工具抱有过高的安全期望。 这种「虚幻的安全感」是很危险的。 |
 |
109
k3Sv1 2020-10-07 08:50:10 +08:00 via iPhone
对不了解的东西可以谦虚一点
|
|
110
k3Sv1 2020-10-07 09:00:15 +08:00 via iPhone
你以为大家说 lol 信任腾讯是在说腾讯不可信，其实是在说你信任腾讯+不信任其他服务商（境外）很可笑。
在没有可靠的信任链时，从安全的角度会认为都不可信。另外，信息安全里说的信任和日常用语的信任并不是一回事，而楼主似乎并没有这个意识。不然你这么“信任”腾讯，干嘛还要加密存储？ |
 |
112
Netizen2 2020-10-08 12:49:44 +08:00 via Android
這種東西自己用就可以了！
|
 |
113
yolee599 2020-10-09 16:35:03 +08:00
腾讯值得信任？ 360 网盘，UC 网盘，115 网盘……一系列的事情让我不再相信任何一家云储存服务了，至少要本地 + 网盘双备份
|
 |
114
acess 2020-11-24 21:43:14 +08:00
挖个坟……其实我有点心疼楼主。在安全 /技术问题上我是个糊涂虫，不过有些话我还是不吐不快。
首先就是开源与信任，虽然我是外行，但是，这方面有篇文章对我影响比较大（里面实际上转述了 Bruce Schneier 的观点），作者是江宏，标题是： 加密货币与区、块、链（三）：什么是信任 不知道楼上朋友的看法，比如 @wevsty ？ 其次，人是天生的政治动物，很多人考虑问题都不自觉地会带入政治思维（或者说 tribalism ），非我族裔其心必异（或者反之）。这一点上我也是个小白，所以不胡乱展开了，我提这个只是一种模糊的感觉。 不过最后很遗憾，我也还是不太欣赏楼主的作品。 虽然我也用微信，对微信的信任程度也很高，但是我的手机比较老旧，微信实际上也相对不常用，加载速度让我感觉很慢。 @chenshaoju "国内隐私和数据保护做的确不好，先不说各种黑产，个人数据到处卖也不是什么少见的事情，这都 2020 年了，各种垃圾短信你也没少见吧？" 依我看，你说的这些问题，相比上文讨论的数据安全（保密）问题，范围一下子拓宽了太多。“各种黑产”“个人数据到处卖”“各种垃圾短信”这种事情，我不太了解国外是什么情况，但是，有证据表明国内就一定比国外差很多么？ 其实我印象里，一提到国外的信息安全事故，我就想起信用卡信息泄露。比如 metzdowd 密码学邮件列表（ bit coin 最初就是在这里发布的）的管理员就吐槽过，信用卡是世界上绝无仅有的，账号和密码是同一个字符串的系统。 连 Google 开发的 Chrome 都把 HTTPS 的描述改成了“您的信用卡信息不会外泄”——我不知道专业人士怎么看，但以我这个半吊子的眼光来看，我只能哑然失笑…… 虽然在三五行字里描述实现了公钥密码的 HTTPS 能提供什么好处确实有点难，这很显然是想要让文字变得“通俗”，但是，这牺牲掉了信息的准确性。 即便是用了 HTTPS，在服务器和用户两端，都仍然是可能发生信用卡信息外泄的，比如系统被黑、被植入木马，这个木马甚至只可能是一个不起眼的恶意浏览器插件。而且据我所知 HTTPS 有些时候也并不是从头到尾都完全保密，很多时候为了让 CDN 能够工作，CDN 服务器实质上是进行了“中间人攻击”，完全知晓通信内容的明文。 |
|
115
acess 2020-11-24 21:50:48 +08:00
在信息安全方面，我作为一个用户，一直都感到很无力。就好像“暗云”引导区木马，“引导区木马”这个词听起来像是上个世纪的事情，毕竟现在新出厂的电脑默认都是 UEFI+SecureBoot 了，但是实际上这个东西并没有绝迹，各种“格式化重装还是蓝屏”（估计是只格式化了 C 盘，没重写 MBR 里的引导代码）还是经常出现。
上网，不知道是不是哪里有 XSS 漏洞，不知道是不是点了什么东西账号就会莫名其妙被劫持走，然后发个菠菜广告都是轻的，鬼知道里面的信息被轮了几次。 即便是关掉浏览器，也不知道系统里有没有什么奇怪的 dll，或者其他形式的木马偷偷潜伏在内存里。也许定期重装系统是个好主意，但是到目前为止我还是得过且过，懒得折腾。 |
|
116
acess 2020-11-24 22:31:50 +08:00
@chenshaoju
"微信小程序没办法在开发工具里方便的查看" 我没有开发过、也没有逆向过微信小程序。 不过就“跳一跳”这个小游戏来讲，我搜索过，看上去逆向并不是不可能，无非就是成本问题。而且反过来讲，就算代码是开源的，也很难说就一定没有暗藏陷阱吧。 还有，其实我本来就不想比较什么国内国外的问题（这貌似还触犯 V 站的忌讳了？也可以理解，毕竟这种事情吵起来没有止境），也不想给国内辩护。 怎么说呢，我也说声对不起吧，让楼主的帖子歪楼了，啰嗦那么多都是纯牢骚…… |
|
117
acess 2020-11-24 22:37:53 +08:00
@wevsty 关于 KDF，我有个理解，不知道是否正确：
实际上，密码只要稍微增加几个（可靠随机的）字符（也就是熵值增加），就可以起到和 KDF 类似的效果。 （也许现在的 KDF 不仅增加计算成本，还增加了内存消耗？这样情况又略有不同了） 换言之，KDF 只是一种缓解问题的手段，“成千上万倍”听起来很厉害，实际上未必有那么神奇。 |
|
118
wevsty 2020-11-25 00:01:34 +08:00 1
@acess
信任是个很宽泛的词语，不太好一概而论。 在本贴里的案例来说，信任分为 2 个层面。 1 、是对个人的信任。 2 、是对事实的信任。 对个人的信任每个人有不同的想法，你可以相信某个人不会刻意去做危害你的事情，也可以相信某个人会因为各种各样的目的来危害你。大多数情况下因为其不可证伪性，这个问题没有绝对正确的答案。 为了克服对个人信任的不确定性，人类需要可以证明或者证伪的事实来确保信任。 正确的开源本身保障了： 1 、开发者难以通过插入恶意代码来危害用户。即使用户自己不懂代码，只要一旦存在恶意代码会很容易被人审查到并且披露出来。因为源代码人人都可以看到，不可能所有审查代码的人都自己主动包庇开发者，所以我们可以相信恶意行为会被披露。 2 、通常开发者会直接提供二进制文件供用户直接使用，开发者仍然可能在二进制文件上动手脚，开源保证了如果用户不信任开发者提供的二进制文件可以自行来制作二进制文件。 基于这两点来考虑开源之后对开发者的信任就不再重要了。因为可以相信社会上一定存在懂代码的好人，所以如果有问题这么一群人一定会指出来。 政治因素无法扭曲这个逻辑过程，所以政治因素不会影响这个结论。 至于 KDF 的问题 增加密码的熵值并不能起到和 KDF 一样的效果，原因是对于这种对称加密来说密码必须是可重现或者可预测的，而增加再多的熵都只能是一次性的，并且增加的熵必须要以某种方式来保存，所以找到增加的熵的时间必然很短，这并不能起到抗穷举攻击的作用。 单纯给密钥增加一个随机熵的思想密码学上通常是用来预防查表攻击的。 原因是任意的加密算法只要给完全一致的参数都会得到完全一致的结果，所以对于常见的加密结果我们可以通过预先生成的结果来比对加快破解的速度。增加随机熵后因为随机熵不可预测，所以不可能预先生成结果来比对。 具体到实践上，一种典型的实践方式是使用加盐密码哈希，以此来对抗查表攻击。 使用 KDF 时要得到解密所需要的密钥就必须符合下面的过程： 解密所需要的密钥=KDF(密钥， 随机盐， 迭代次数) 尽管单次 KDF 运算所需要的时间很短，但是由于有迭代次数的存在，即使知道了全部正确的参数，不执行迭代次数次的 KDF 函数仍然无法得到正确的密钥。 迭代次数增加将会拉长得到解密密钥的时间，提高攻击者的时间成本实质上就是降低了攻击者再有限时间内能尝试密码的次数，所以说 KDF 是能抗穷举攻击的。 |
|
119
acess 2020-11-25 00:20:09 +08:00
@wevsty
首先，即便这个楼主开源了，可能还是有很多人不愿意信任他——恕我直言，（以我这个半吊子自己的感觉来看）我觉得这很大可能上并不是出于什么缜密的思考，而是出于某种（尤其是，很可能是经过刻意策划，宣传灌输进去的）偏见。至于受这种偏见影响会不会有害，这个其实是另外一回事（很多广告打得响的东西，说不定其实质量真不差）。这就是我为啥要提政治……我觉得几乎没人能在这方面完全免俗吧。 还有，说到开源，其实有个小细节：可重现编译（ deterministic build ），这个貌似也就比特币一直在用。如果我没理解错，这个过程是：一样的代码，用同样的软件环境，经过同样过程，编译出一个字节不差的二进制代码，由此证明代码和二进制是对应的。 但是，因为有 Ken Thompson Hack 的存在，再有就是“即便开源、而且源码真的忠实地编译成了二进制，也未必能从代码中找到逻辑 bug”这个问题，好像这个概念本身还是有点鸡肋的。 后面给密码增加熵，我感觉你说的貌似是加盐？怪我表达不当。既然密码管理器就是个人用途，那我觉得好像不涉及撞库之类的问题。我只是觉得，KDF 这个概念本身应该也是可以“驱魅”的。 （我第一次看到 Argon2，是好奇折腾 Ubuntu 的 dm-crypt 、想搞全盘加密的时候。稍微搜了一下，好像设计确实考虑周全，加入了针对侧信道攻击和 GPU 破解的对策，对于后者，我感觉这可能和加密货币抗 ASIC 挖矿算法有点类似？然后说实话，我不知道这类设计到底有多有效，毕竟不少抗 ASIC 的 PoW puzzle 最后还是出现 ASIC 矿机了，效律比 SHA256 的情况差很多，但是仍然是碾压程度的高效） |
|
120
acess 2020-11-25 00:26:53 +08:00
@wevsty 我第一次看到加盐这个概念时，也非常折服，印象中大概是“即便被拖库也仍然能保证安全”，但是后来仔细想了一下，现实中好像还是蛮鸡肋的——都拖库了，可能有价值的数据本来就已经一波带走了，说不定服务器后端什么的都被注入了恶意代码，被攻击者实时视奸着呢？
打个可能不恰当的比方，就好像 WinPE 破解 Windows 登录密码一样……即便不去破解出明文的登录密码，实际上系统里有啥，绝大部分也已经都一览无余了。 不能说这样没意义，意义还是很大的（我记得 Windows 账户密码实际上也确实被用来加密凭据，包括证书私钥、浏览器登录密码之类的），但是好像没有我这个外行一开始想象得那么神奇。 |
|
121
acess 2020-11-25 00:33:26 +08:00
@wevsty KDF 这个东西，我记得在哪里看到过，本来就是因为人脑想出来的密码熵值不够高（具体熵值有多少，貌似也是根据具体情况的，取决于破解者猜测密码的能力，“会不会编字典”，好的字典能大大缩小搜索范围），现实中想让人类想出熵值够高的密码又太难，所以就有了这么个既不打扰用户，又能弥补“人脑想出的密码熵值低”这个缺陷的技术。
所以……我就有了一个暴论：如果可以直接用靠谱的办法生成随机密码，然后人脑可以直接记下它，那（从个人使用角度考虑，而不是从“宏观”的视角来看）效果和用了 KDF 也差不多。 （如果一个密码在多个地方被重复使用，那问题就很大了……不过，能想到用密码管理器的人，让他不要犯这种低级错误，貌似也不难吧） |
|
122
acess 2020-11-25 01:07:46 +08:00
@wevsty 我会想到这个暴论，主要是因为我看过对于比特币脑钱包的批评。
比特币的账本全部是公开透明的，就好像一个天然公开的“账户密码数据库”，而且没有加盐、没有 KDF——传统的比特币脑钱包就是把人脑想出来的密码简单地哈希一遍，然后就直接用作私钥了，接着，从私钥得到公钥、地址这个计算也没啥成本。 攻击者只要暴力穷举，找到私钥，就可以直接把币转走。 所以说，解决这个问题的对策，就是用轮次足够多的 KDF 加盐？ 很显然这样就跑偏了，不是么。 如果我没理解错，KDF 对于攻守双方是平等的，想要 KDF 增加多少强度，用户自己在正常使用的时候也要付出等同的计算量代价。换句话说，引入 KDF 后，每次输入密码时，机器“卡”了多久，就代表密码被 KDF 增强了“这台机器能够在这么长的时间内，能够穷举破解出的密码”这么多的强度。 KDF 的轮次不可能无限地往上加，于是，通过 KDF 得到的强度提升也很有限。 换句话说，再怎么折腾 KDF，也不可能让本质上就不安全的脑钱包安全到哪里去。 现在比特币的钱包一般都是用一个助记词来作为随机种子生成私钥，最常见的 BIP39 助记词是 2048 个单词表里随机抽取的 12 个单词，用来编码表示 128bit （ 132bit 里有 4bit 被用作 checksum 了）的熵。 不过说实话，比特币貌似也并没有解决这个问题……而且 BIP39 助记词里也是用了 KDF 的（大概是因为除了 12 个单词本身之外，还是一个可选项 passphrase，也是人脑想出来的附加密码）。 现在主流的钱包会引导用户把助记词写到纸上，和柯克霍夫原则里的“密匙必须易于沟通和记忆，而不须写下”，也是背道而驰吧。 |
|
123
wevsty 2020-11-25 10:01:27 +08:00
@acess
假设 KDF 的迭代次数高到用户的 CPU 需要 10 秒来得出结果，对合法用户只需要支付一次运算代价。 一个简单的 6 位数字密码存在 10^6 （ 100W 次可能），假设平均尝试 50%的组合即可攻击成功。 那么攻击者在使用同型号 CPU （假设 CPU 为 16 逻辑核心）时攻击时间则需要 500000 * 10S / 16 = 312500S 大约需要 87 小时来攻击成功。 如果不使用 KDF，通常尝试一个密码只需要毫秒级的时间（或者更少），假设只需要 100MS 即可尝试一个密码，同等条件下只需要 500000 * 0.1S / 16 = 3125S 也就是大约 52 分钟即可成功攻击。 毫无疑问的，KDF 在这里显著的提高了穷举的难度，并且当 CPU 的性能发生改变时，能迅速有效的的抵消性能提升带来攻击成本降低。 KDF 的迭代次数在理论上是无限的（具体到实践中虽然是有限的但是数字非常大，大到你绝对不会想去用到那么大）。 P.S：在我个人的实践中，KeePass 对保存数据库密钥的 AES-KDF 次数是 50W-100W 次，这仅仅只需要 1 秒的运算代价（单核心的状况下）。 此外，不同的算法在不同的场景下，作用可能是不一致的。 比如某软件就是通过 HKDF (HKDF 是 KDF 的一种典型实践) 来变换加密的密钥，使用 HKDF 的目的主要是让密钥不会重复的使用，而不是为了要拖慢暴力攻击的速度。 比特币的技术细节我个人不了解，不做任何评论。 |
|
124
acess 2020-11-25 11:42:26 +08:00
@wevsty
简而言之，根据我的认识，KDF 是很有意义的技术，尤其是可以防止大规模、跨网站的撞库；但并不能因此神化它（不过我并没有说你有意在神化它）。 “成千上万倍”，这种叙述可以给人直观印象；但实际上，它真的有化腐朽为神奇的、不可思议的效果么？我感觉，未必。 我之前提到“KDF 和几个随机字符效果差不多”——我的这个叙述同样是不准确的。“合法用户只需要支付一次运算代价”，这个我还是知道的。 提比特币，是基于我之前提到的一个理解：“之所以会有 KDF，根本上是因为人类很难设置、记忆熵值够高的密码”。比特币用 12 个单词的助记词，即可表示 128bit 的熵，在我看来还是很有启发意义的，虽然实际上比特币钱包还是放弃了让用户记忆这 12 个单词（本来“助记词”这个名字就是“辅助记忆”的意思，不是么），转而引导用户把它抄写下来，所以还是绕回了问题的原点、没有很好地解决这个问题。 |
|
125
acess 2020-11-25 11:55:04 +08:00
@wevsty 回到楼主这个作品上……
其实网盘云备份，就不是黑箱了么？同样是黑箱不是么。要说封号，网盘同样可能封号，无非就是封号的缘由（以及几率）可能不太一样。 理论上微信小程序也许可以被腾讯篡改——这里我又要拿比特币类比了，比特币官网在推荐钱包软件时，有一个扣分项，就是“远程加载可执行代码”（案例就是类似 blockchain. info 、btc. com 之类的 web 钱包）——看上去微信小程序在这一点上就不幸中招了。 “远程加载可执行代码”为啥会成为扣分项，我觉得不难理解，应该还是因为“确认公开的源码是否对应实际执行的代码”这个问题吧，理论上网站如果被黑或者作恶，随时可以偷换成恶意代码。 但是呢，即便是讲究“去信任化”到极致的比特币，好像也没有在官网上直接“下架”这种有扣分项的钱包。虽然这确实是一个扣分项，但这个扣分项好像也并不至于那么致命吧。 最后，包括我自己在内，看到楼主这个帖子，可能很多人脑内第一个浮起来的概念是“国内 /国外”，哪怕想起“经过剪贴板可能不安全”都不是第一反应。 |
|
126
acess 2020-11-25 12:12:32 +08:00
@wevsty （啊，好尴尬……发完帖子才发现，其实网页钱包现在已经从比特币官网的推荐列表里删去了……不过我还不知道具体理由。稍微搜了一下，下架 btc. com 的理由貌似是 HSTS PKP 时间不够长）
|
|
127
wevsty 2020-11-25 12:13:29 +08:00
@acess
你应该去做威胁模型分析。 安全通常是要建立在一定前提下的，如果假设攻击者有无限的资源，无限的情报，无限的等等等，那就不存在任何安全。 以 KeePass 来举例我们以攻击者的视角来看，要得到用户密码必须具备 2 个条件： 1 、得到用户的数据库文件 2 、得到用户使用的主密钥 这两个条件缺一不可，把数据库备份到网盘上这一个单一的行为并不会导致密码泄漏，因为网盘不知道用户主密钥。 网盘服务商要是作为攻击者想穷举密码需要付出巨额的代价，这不符合经济原则，所以才可以确信数据库存在网盘上不会导致密码泄露。 至于网盘服务商封号，拒绝提供服务，也还是无法得到保存的密码，所以实际上跟安全性无关。 反过来也是一样，如果有人知道主密钥，拿不到数据库文件也没辙。 这里创建的先决条件有多难就决定了安全的上线在哪里，超过这个上线的讨论是没有意义的。 |
|
128
acess 2020-11-25 12:19:41 +08:00
@wevsty （稍微搜了一下，比特币官网的情况，貌似是最后一个 web 钱包被下架了，在这之后才连带删掉整个 web 钱包分类。最后一个 web 钱包是 Coin Wallet，不过下架的理由好像主要是没有告知的收费，貌似还不涉及“远程加载代码”这个问题）
|
|
129
acess 2020-11-25 12:29:16 +08:00
@wevsty
首先我没有假定攻击者拥有无限的资源……实际上放我自己身上，我肯定愿意用带有现代 KDF 的产品，以“输密码时卡上几秒”的代价，换取安全性显著提升（按我的理解，就是等效于密码被追加了好几个难记的随机字符，有了 KDF，我不用记忆它们也能达到一样的效果，更不用提对跨站撞库的防御），很显然是值得的。 不过，我也不知道一个现代的 KDF 在典型情况下到底能增加多少强度。 其次，我觉得“安全性”这个概念不止涉及保密性吧？可用性其实也是安全的一个范畴。比如勒索病毒把文件加密了，这很显然是安全事件，但是未必涉及泄密（虽然有些勒索黑客现在确实在用泄密作为要挟条件）。 “反过来也是一样，如果有人知道主密钥，拿不到数据库文件也没辙。” 确实是这样。但是我觉得有不少情况，比如电脑中键盘记录木马这种情况，都已经拿到主密钥了，这可能已经是整个系统被攻陷的情况（对于个人用户来说，管理员特权也许不是特别重要，就像 xkcd 1200 ），顺带着拿到整个数据库也就不是难事了。 |
|
130
wevsty 2020-11-25 13:03:54 +08:00
@acess
KDF 能为密码管理器这种用途增加多少强度这种问题并没有固定答案，因为 KDF 的算法，盐，迭代次数都是你自己定下来的，每个 CPU 的性能也是不一样，要加密的数据大小也未必是固定的，这里变量太多，没办法得到确切的数字。 只能说你用的 CPU 性能如果是顶尖水平，并且支付了对应的时间代价，那么其他人使用同等或者更差的 CPU 就需要尝试次数*代价时间 / CPU 核心数量次以上的代价。 当然，安全除了保密性还包括可用性之类的内容，这就是为什么要分析威胁模型。 有人直接物理上给你在 PC 上安装监视系统怎么去防护？ 如果有人拿枪要你交出密码和数据库你要怎么防护？ 如果有人能直接把你关进去，不让你接触密钥文件你要怎么防护？ 如果你问我这样的问题我的答案是无法防护。 这种讨论实质上就是假设了攻击者无处不在（本质上无处不在也是一种无限资源）。 |
|
131
acess 2020-11-25 13:48:13 +08:00
@wevsty 我感觉你似乎有点误解。我并没有问 50 元扳手攻击这种问题（虽然我的想法和 50 元扳手攻击也差不了太多了）。
但是，如果你要问我，我能保证我的电脑系统完全干净么？我没有信心回答“能”——这并不是因为我把电脑物理上随随便便给了陌生人使用，而是因为我并不是个“清教徒”式用户，很多时候我也会“从网上乱下东西”（比如 V 站一直在抵制的，盗版 /破解）。 即便我说了类似“大概可以吧”，这样的答案，也是觉得“如果不这么想，那电脑就压根不能用了，因为每时每刻都有被害妄想（笑）”。 “有人直接 [物理上] 给你在 PC 上安装监视系统怎么去防护？” 很多时候并不需要物理上进行这个动作——当然，即便不是物理上这么做，这个问题大概也还是无解，甚至是没有什么意义。 |
Select Language