以安全的方式向服务器发送密码

Question

我目前正在为我的一个网站开发一个更好的登录例程,我想安全地将登录数据传输到服务器.关于这个主题有几篇文章和帖子,但他们经常对如何完成这些文章和帖子有不同的看法.

从SSL开始,漂亮的每个人都在同一页面上:你应该使用SSL,我这样做.然后有人说:"这就够了,使用SSL,你可以发送用户名和PW作为明文".我不同意.其他人说它应该仍然是哈希.我读了几篇文章,我觉得人们关心登录例程的不同方面,并建议只处理其安全方面的机制.

所以我想知道的是,如果我到目前为止所阐述的例程是足够的,太多或太少.我将尝试解释为什么我选择实现某个功能以及我尝试涵盖的安全方面:

1. SSL:

服务器和客户端之间的通信应该始终是https:// - 尽管如此,我读了几篇文章警告SSL是"没有银弹",但这是一个好的开始.

2. Hash PW clientside(SHA3,ARGON2i,BCRYPT):

许多评论确实拒绝了PW.使用散列,将其与数据库中的HASHed PW进行比较只会将PW从用户输入更改为HASH - 攻击者仍然可以通过简单地获取HASH来访问.我同意.但是(这是我的意思是人们阅读安全的不同方面)那些声称它比发送明文更好的因为在那种情况下只有你的系统,而不是其他具有相同PW的系统会受到损害(当然,除非他们也使用哈希PW).所以我会在通过SSL发送之前实现密码的HASHing.

3. 加密HASH:

假设SSL无法隐藏我们发送给服务器的数据,攻击者会读取HASHed PW.我可以考虑调整此方案的安全性的唯一方法是使用事先由服务器发送的密钥加密(例如,AES CBC)客户端HASHed PW,并且具有短的有效期.密钥必须随机生成.像这样,服务器可以解密数据,然后将HASH与数据库中的HASH进行比较.

把它们加起来:

- >客户希望通过SSL进行登录 - >服务器返回键 - > PW的客户方哈希 - >用密钥和随机IV德HASH的客户方加密 - >服务器与密钥(存储在$ _SESSION解密数据,具有到期时间戳)并将HASH与其DB中的HASH进行比较(如果到期时间戳仍然有效).

这会是一个好方法吗？或者这太多了？(可以有太多安全措施吗？)或者您有其他替代解决方案吗？

Answer 1

或者这太多了？(可以有太多安全措施吗？)

你说的就像安全是一种液体,必须填满容器而不会溢出它.这不是它的工作原理而你提出错误的问题,这意味着你正试图解决错误的问题.它与您累积的措施数量无关,但它们是否以及如何解决特定问题.

如果问题在于保护传输中的数据,那么解决方案就是TLS(SSL) - 这就是它专门设计的内容,在最好的情况下,你能想到的任何东西都是它的不良替代品.你不能超越已经进入TLS的数十年的研究和实践.

杰伊布兰查德已经回答了这个问题,但是......我想指出你所犯的错误,因为否则它看起来就像一个人对另一个人的说法(你可能会听,但其他读者可能不会):

1. SSL:

服务器和客户端之间的通信应该始终是https:// - 尽管如此,我读了几篇文章警告SSL是"没有银弹",但这是一个好的开始.

它既是银弹又不是银弹,取决于你如何看待它.

当我们谈论保护传输中的数据时,它就是解决方案 - 在某种程度上是一颗银弹.

但这并不意味着没有及时找到缺陷,或者你只是打开它并说"我有TLS,我很安全!" - 不,它仍然需要适当的配置,维护和长期调整.从这个意义上说,它不是一颗银弹.
它也没有解决许多其他安全问题,所以当有人问"我如何使我的应用程序安全？"时,你当然会说这不是一个银弹 - 许多威胁需要单独解决而且没有人 - 为他们所有的商店.

2. Hash PW clientside(SHA3,ARGON2i,BCRYPT):

许多评论确实拒绝了PW.使用散列,将其与数据库中的HASHed PW进行比较只会将PW从用户输入更改为HASH - 攻击者仍然可以通过简单地获取HASH来访问.我同意.但是(这是我的意思是人们阅读安全的不同方面)那些声称它比发送明文更好的因为在那种情况下只有你的系统,而不是其他具有相同PW的系统会受到损害(当然,除非他们也使用哈希PW).所以我会在通过SSL发送之前实现密码的HASHing.

这恰恰相反 - 当您在客户端散列密码时,只会使您的网站上的帐户在数据泄露后更容易妥协.

查找数据库中的哈希 - 在那里获得密码,这是你想出的部分.但是这个哈希仍然是某个用户提供的字符串的结果......没有什么能阻止攻击者使用相同的技术来破解哈希以便破坏其他服务器上的帐户.

所以,这并没有以任何方式解决问题,但你可能会认为在最坏的情况下,它没有做任何坏事......嗯,间接它确实 - 你必须做出相当大的努力,实施有很多潜在错误的东西.
在最好的情况下,你只是在浪费你的时间,但一个小错误可能是一个主要的漏洞.

此外,SHA-3是一个加密原语 - 它有许多设备,但主要是作为构建块.你不能只把它的一轮放在密码上,并对产生的哈希感到满意.
为了进行比较,bcrypt在内部使用Blowfish(作为与SHA-3相同类型的原语),但是你不能将Blowfish等同于bcrypt.

3. 加密HASH:

假设SSL无法隐藏我们发送给服务器的数据,攻击者会读取HASHed PW.我可以考虑调整此方案的安全性的唯一方法是使用事先由服务器发送的密钥加密(例如,AES CBC)客户端HASHed PW,并且具有短的有效期.密钥必须随机生成.像这样,服务器可以解密数据,然后将HASH与数据库中的HASH进行比较.

加密密码哈希有正当理由,但不是为了这个目的,当然也不是在客户端.

您需要一个安全的密钥交换协议才能实现这一点.猜猜你是怎么做到的？TLS.

通过网络传递加密密钥或密码几乎没有什么不同.所以,即使这在某种程度上是保护密码的解决方案,你如何再次在密钥本身上应用它？这没有道理.