考虑到大型网站通常如何登录,似乎公司服务器在内存中以明文形式显示您的密码。这是真的,是否安全?
这类似于大多数大型网站的登录方式:
查看步骤4和5之间的
使用非对称加密私钥解密密码
4.5。简要介绍一些带有纯文本密码的服务器端变量
这意味着虽然整个哈希方案是为了防止攻击者获得密码访问权限,即使服务器遭到入侵,但是技术娴熟的黑客无论如何都可以获取密码。
我错过了什么吗?更重要的是,是否有更安全的替代方案?
答案 0 :(得分:2)
是的,它是“安全的”,因为内存中的任何内容都在服务器的内存中,并且不应该能够从外部读取。
安全是引用的,因为一切都是相对的,风险等级取决于你所感知的威胁模型 - 即你想要防御哪些威胁?
广为人知的Heartbleed错误允许攻击者以64KB的块从服务器的内存中检索项目。但是,这里的策略是实施漏洞管理(修补过程),而不是围绕这些类型的问题进行编码。
关于加密密码 - 这是你应该依赖HTTPS而不是在Javascript中在客户端加密它们的东西。当他们到达您的服务器商店并使用慢速算法(如bcrypt,scrypt或pbkdf2)以散列格式比较它们。还可以使用标有安全&的cookie。仅http标志,实施HSTS策略,你应该好好继续密码存储和传输。
CERT关于处理内存中敏感数据的建议is here。
与您的问题最相关的部分是:
这意味着整个哈希计划是为了防止 即使是服务器,攻击者也可以访问密码 无论如何,技术娴熟的黑客都会受到攻击。
请记住,拥有一个安全的系统不仅意味着您需要安全的编码实践和安全的基础架构。这是因为您永远不会有100%的安全性。这可能缺少的部分难题是任何形式的入侵检测/预防(IDS / IPS)。这会认为系统在某些时候会受到损害,因此您不是试图阻止所有可能的攻击类型,而是检测它,允许您采取适当的立即行动。如果攻击者设法破坏您的系统并在登录过程中到达时开始收集凭据,这将覆盖您。
答案 1 :(得分:0)
你是对的。远程攻击者必须更改代码。这可以很容易地为PHP完成,但对于编译语言则不是这样。混淆的PHP代码也有阻碍攻击者努力的地方。
当攻击者是其中一个开发人员时,有时甚至编译或混淆的代码也无法阻止攻击。
请注意,在用于用户身份验证时,可能会以相同的方式破坏多方通信和零知识证明。除了让攻击者真的很难闯入你的服务器之外,我不认为还有其他选择。
答案 2 :(得分:0)
这类似于大多数大型网站的登录方式
实际上,我从未见过任何网站加密密码客户端。在客户端上加密然后在服务器上解密它几乎没有任何收获。这就是SSL证书的用途。我生命中见过的几乎所有网站都只是以明文形式将密码发送到服务器,然后在那里哈希(我们希望)。
如果您试图阻止服务器在内存中使用纯文本密码,您可以在客户端散列它,然后在服务器上散列哈希值。请记住,当您在客户端上散列密码时,散列实际上会成为密码。