@acess
你应该去做威胁模型分析。
安全通常是要建立在一定前提下的，如果假设攻击者有无限的资源，无限的情报，无限的等等等，那就不存在任何安全。

以 KeePass 来举例我们以攻击者的视角来看，要得到用户密码必须具备 2 个条件：
1 、得到用户的数据库文件
2 、得到用户使用的主密钥
这两个条件缺一不可，把数据库备份到网盘上这一个单一的行为并不会导致密码泄漏，因为网盘不知道用户主密钥。
网盘服务商要是作为攻击者想穷举密码需要付出巨额的代价，这不符合经济原则，所以才可以确信数据库存在网盘上不会导致密码泄露。
至于网盘服务商封号，拒绝提供服务，也还是无法得到保存的密码，所以实际上跟安全性无关。
反过来也是一样，如果有人知道主密钥，拿不到数据库文件也没辙。

这里创建的先决条件有多难就决定了安全的上线在哪里，超过这个上线的讨论是没有意义的。

@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 的目的主要是让密钥不会重复的使用，而不是为了要拖慢暴力攻击的速度。

比特币的技术细节我个人不了解，不做任何评论。

@acess
信任是个很宽泛的词语，不太好一概而论。
在本贴里的案例来说，信任分为 2 个层面。
1 、是对个人的信任。
2 、是对事实的信任。

对个人的信任每个人有不同的想法，你可以相信某个人不会刻意去做危害你的事情，也可以相信某个人会因为各种各样的目的来危害你。大多数情况下因为其不可证伪性，这个问题没有绝对正确的答案。

为了克服对个人信任的不确定性，人类需要可以证明或者证伪的事实来确保信任。
正确的开源本身保障了：
1 、开发者难以通过插入恶意代码来危害用户。即使用户自己不懂代码，只要一旦存在恶意代码会很容易被人审查到并且披露出来。因为源代码人人都可以看到，不可能所有审查代码的人都自己主动包庇开发者，所以我们可以相信恶意行为会被披露。
2 、通常开发者会直接提供二进制文件供用户直接使用，开发者仍然可能在二进制文件上动手脚，开源保证了如果用户不信任开发者提供的二进制文件可以自行来制作二进制文件。
基于这两点来考虑开源之后对开发者的信任就不再重要了。因为可以相信社会上一定存在懂代码的好人，所以如果有问题这么一群人一定会指出来。

政治因素无法扭曲这个逻辑过程，所以政治因素不会影响这个结论。


至于 KDF 的问题


增加密码的熵值并不能起到和 KDF 一样的效果，原因是对于这种对称加密来说密码必须是可重现或者可预测的，而增加再多的熵都只能是一次性的，并且增加的熵必须要以某种方式来保存，所以找到增加的熵的时间必然很短，这并不能起到抗穷举攻击的作用。

单纯给密钥增加一个随机熵的思想密码学上通常是用来预防查表攻击的。
原因是任意的加密算法只要给完全一致的参数都会得到完全一致的结果，所以对于常见的加密结果我们可以通过预先生成的结果来比对加快破解的速度。增加随机熵后因为随机熵不可预测，所以不可能预先生成结果来比对。
具体到实践上，一种典型的实践方式是使用加盐密码哈希，以此来对抗查表攻击。

使用 KDF 时要得到解密所需要的密钥就必须符合下面的过程：
解密所需要的密钥=KDF(密钥， 随机盐， 迭代次数)

尽管单次 KDF 运算所需要的时间很短，但是由于有迭代次数的存在，即使知道了全部正确的参数，不执行迭代次数次的 KDF 函数仍然无法得到正确的密钥。
迭代次数增加将会拉长得到解密密钥的时间，提高攻击者的时间成本实质上就是降低了攻击者再有限时间内能尝试密码的次数，所以说 KDF 是能抗穷举攻击的。

可以问一个现实的问题，ARM 服务器可能只能运行定制的 Linux 内核你能接受么？

抛 std::bad_alloc 很有可能是内存用完了。
检查内存泄漏和运行机器的空闲内存看看吧。

@elfive
auto_ptr 虽然废弃了，但是不是也对应的推出了 shared_ptr,unique_ptr,weak_ptr 这么一套么。
使用智能指针仍然是现代 cpp 推荐的使用方法。

另外 boost 虽然有一些槽点，但是并没有觉得不稳定。

光猫开了 dmz 或者端口转发一类的转发了外部的登录请求吧

那些基金蚂蚁最多也只占 10%，而且目前蚂蚁也没有说就不上了，只是暂缓。
你想退钱基本上是不可能的。

一般的地方可以继续用。
银行之类的地方可能会拒绝你使用旧身份证。

TP-Link 家基本上是出厂固件用到死，不要指望任何固件更新。

那你既不愿意安装二进制的包，又不愿意装编译器从源码来编译，还能怎么办？

LTSC 没有这个 feedback

检查有没有循环引用数据结构的问题。

@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 、这些问题是一开始你就应该说明的，也许说明清楚有些人的看法会有所不同。

看来楼主还是不明白。

对于密码管理器这种东西，安全体现在 2 个维度上。
1 、数据的保密性
1.1 对于数据的保密性，仅有楼主自称采用了什么算法来保证，并没有任何的证明。
只贴个加密库的开源地址是没办法说明任何问题的。
1.2 对这类产品用户同样需要信任开发者
以目前的言行来看谈不上对开发者的信任。
1.3 对操作环境的信任
就跟大家都知道不应该在不信任的环境下输入密码一样。
微信对于公众来说是黑盒无法指定它内部是怎么样实现并且会做什么，而你的程序完全依赖于微信这个黑盒。
大家的回帖已经充分说明了，显然对于注重安全的群体来说是无法信任的。

2 、数据的储存的可靠性
基于数据是加密保存的前提下，数据储存的可靠是另一个问题。

微信云提供的免费空间始终是免费提供给你的，这种免费服务是随时可以取消，不应该把数据的唯一希望寄托于这种免费的服务。
另外有人问微信封号怎么办？你只回答要正确使用微信。绝大多数人都是没办法接受这种答案的，因为封号不封号是不可控的，应该也不会有人愿意以限制自己为条件来使用这个可替代的产品。

一直纠结究竟是国内还是国外的服务可信是没有意义的，因为任何非自己物理上可控制的设备都不可以彻底的信任，这才是数据必须加密储存的原因。
此外还要要预防数据丢失的问题，任何单一的储存介质都是不可信任的，这是基本原则。数据储存在微信云虽然腾讯保证数据的可用性，但是仍然是不应该信任的。数据能否自己导出这个问题楼主你自己并没有说明，就算可以，用户依然无法不依赖于微信来使用，这是个很大的问题。



最后，无论楼主的产品怎么样，被人拿来和其他产品比较是不可避免的。
对比我使用的 KeePass 来看：
KeePass 开源。楼主的程序没有开源。
KeePass 针对各种两步验证提供了解决方案（比如：TOTP ）。楼主的产品对此毫无说明。
KeePass 针对对密码管理器的各种攻击做了足够多的措施（比如：对抗密码穷举）。楼主的产品对此毫无说明。
KeePass 本身只依赖于操作系统，并且在多种操作系统上都有对其协议的实现。楼主的产品必须依赖于微信。
KeePass 的数据可以多地保存（无论是各种云产品还是存在本地的物理介质上），楼主的程序并没有说明这个问题。
所以说对比各类竞品楼主的产品并没有什么优势。

我觉得说了这么多应该是没人敢用的。

Windows 的话可以通过 job 来限制 CPU 使用，也可以通过限制运行再某一个核心的方式来限制 CPU 。
Linux 的话 cgroup 是正解。

另外，恐怕楼主找到的都不是 bug，反倒是乱改可能改出 bug 了。

@vk42
这里的 kill 不是命令行的 kill 而是指 kill().

pid 为-1 时会给除了 init 以外的所有有权限访问的进程都发送一遍指定的信号。
文档写的很清楚：

If pid equals -1, then sig is sent to every process for which the calling process has permission to send signals, except for process 1 (init).

可以想象楼主的焦虑。

我是觉得，只要找到相对稳定的收入，这个焦虑应该能减轻很多。