【问题标题】:WebApp Password Management - Hashing, Salting, etcWebApp 密码管理 - 哈希、加盐等
【发布时间】:2011-02-21 21:33:11
【问题描述】:

我正在寻找网络应用中最安全(但可行)的密码管理方式。

现在,我将密码保存为哈希。该应用程序的数据库帐户仅限于执行存储过程,我通过将用户名和散列密码提供给返回 1(true) 或 0(false) 的存储过程来验证用户。

因此,即使您拥有应用程序的数据库帐户,也没有机会从服务器获取密码。这就是我喜欢这个解决方案的地方。但是要使用它,客户端必须通过网络提交他的密码,或者至少是一个可以被捕获的静态哈希。

所以我想到了使用这样的握手:

  • 客户端向服务器请求盐。
  • 随机盐分给客户端并存储在服务器上供这个单个客户端使用。
  • 客户端生成哈希(盐+密码)并将这个哈希返回给服务器
  • 服务器生成哈希(盐+密码)并检查它是否与客户端相同

使用此握手可以在不发送自身或密码的静态哈希的情况下检查密码。只是一个动态加盐哈希,每次用户登录时都不一样 => 高度安全。

但是对于这次握手,我需要密码或至少来自数据库的散列密码。但这使某人至少可以获取哈希密码并在应用程序之外对其进行暴力破解。

你喜欢什么?将密码保存在数据库中并在那里进行任何操作(安全服务器),或者将其从数据库中取出并在外部进行(安全传输)?

提前致谢, 标记

【问题讨论】:

    标签: database security hash passwords


    【解决方案1】:

    您提出的解决方案并不能真正解决问题。然而,服务器必须知道密码,所以它必须在某个时间点明文传输,这是您首先要避免的。这样你就可以避免每次都重新发送密码,但是如果第一次被转移就被人抓住了呢?

    我认为您不应该重新发明轮子 :-) 对所有连接使用 SSL,然后您的第一个解决方案就可以正常工作。您甚至可以在客户端执行散列,因此只有散列通过安全通道发送。您的服务器永远不会知道密码,也不必知道。

    【讨论】:

    • 同意,SSL 应该足够安全。当然也对数据库中的密码进行哈希处理,尽管这些天怀疑 MD5,所以我可以使用更安全的哈希算法来执行此操作。您提议的握手类似于 MS-CHAP,这也是可疑的。
    • 你是对的,但我认为密码被嗅探的可能性比用户登录的以下数百或数千次之一要小。我的连接是 SSL 越少,我只是想要一些额外的安全性。现在我使用 SHA1 哈希内置的 FormsAuthentications,但我需要在另一个地方使用 SHA-256,所以我想我会切换到那个。您认为存储过程 GetUser 应该返回散列密码吗?还是直接返回 null?
    • 当您谈论“安全”时,您总是假设最坏的情况。您假设攻击者始终存在并以最大效率利用系统中的每个弱点。从这个意义上说,他能读你的密码一次或一百次都无所谓,事实是他能读懂它。您的客户不想听到您说“攻击者不太可能读取您的密码”:-) 您的存储过程是否返回哈希值或null 取决于您,服务器应该通过其他方式保护无论如何都阻止远程访问(防火墙、安全补丁等)
    猜你喜欢
    • 2011-12-06
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2013-09-11
    • 2010-11-30
    • 1970-01-01
    • 1970-01-01
    • 2015-10-24
    相关资源
    最近更新 更多