























39 restkhz 2 月 4 日@Admstor OK, 你想谈安全。 但是! 从设计思路上来说,“口令”这种东西就是要给对方进行验证的。你有 secret,我也有,我要给你看 secret 来证明我有。两端都一定会要存有 secret ,并且在验证的时候这个 secret 一定会被传输。 你觉得哪种设计更安全?以后能暴露的攻击面更少? 你的对手会的不只是暴力破解。secret 出现的地方越多,出问题的可能性越大。我理解你讲的比如如果我密码足够强就算黑客读到/etc/shadow 也破不出来,和黑客拿到公钥没用同理。然而一旦出现 secret 明文本身呢?楼上也有说到 PAM 模块直接拦截读取明文的,这就是问题。但是我们或许应该在一开始就直接掐死这种可能。只要 secret 压根不出现在服务器上,不被传输,就没这些事情了。 我们抛开上面的理论层面的东西, 安全这种东西你永远不能指望用户。用户是可以用 123456 作为密码的,是可以为了看毛片随手运行 exe 并且卸载杀毒软件的。更不要说定期更换密码,16 位大小写数字符号组合。所以不如直接逼着用户用更复杂的一套算了。 所以回到问题本身,我觉得公钥的确是更安全的,从理论和应用上都是。我希望我说清楚了。 顺便我在某个实验室做运维,管理 100+的 OS ,你猜猜我们用什么做 SSH 验证?密码?公钥? 答案:都不是,我们用 kerberos 安全不安全,你得带着威胁模型再讨论。在你提出的问题中,如果仅考虑暴力等等的,你这的确安全。 |
64 loading 2 月 4 日 via Android举个例子吧: 你和两个朋友在玩一个游戏,规则是三个人面对面大声说话,朋友 A 要告诉你一个秘密,只能大声密谋,他如何告诉你。 你可能想到,A 可以用只有你俩知道的事加密,这可以做到,但想加密任何内容比较麻烦而且你无法确认你俩的这个秘密是否已经被 B 知道。 现在请非对称加密算法登场。 你马上生成一对公私钥,大声说出公钥,A 和 B 同时都能听到。(大声密谋) 如果有必要,再大声说出并解析清楚这个算法。(对,完全开源,就是这么牛,你看以前谍战片能这样?) 然后 A 用你这个算法加你俩的秘密,然后将加密后的密文大声说出来,这时,B 也能听到。 厉害的来了。 B 无法解密。 以上就是大声密谋! 如果 B 给你说的是他这边生成的公钥,后面你们通话就都能是密文了,而且就你俩能解开。 如果这个场景你们是通过打电话做的,如果在刚开始的时候,电话线被剪断了。C 在中间给你假装他是 A ,给 A 假装他是你,他给了他的公钥给 A ,然后一直假装,这就叫中间人攻击了。 为了防止这个事,就出现根证书,有一个内置或者其他方式建立的信任树,你可以理解为熟人当面介绍。 大概这么多,不正之处请各位雅正。 |
此内容由惯性聚合(RSS阅读器)自动聚合整理,仅供阅读参考。 原文来自 — 版权归原作者所有。