【问题标题】:Authenticating using pre-shared secret使用预共享密钥进行身份验证
【发布时间】:2012-08-11 02:31:59
【问题描述】:

我们正在开发一个需要安全用户身份验证的 GWT Web 应用程序。我们有可能通过传真向用户提供凭据。所以我们可以使用预共享密钥。我们无法在此应用中使用 ssl 或 https。

我想知道将通行证存储在服务器上并验证用户身份的更安全方法是什么?我怀疑我们应该对密码进行两次哈希处理吗?

【问题讨论】:

  • 为什么不能使用 SSL 和 HTTPS?
  • 这只是因为我们假设它需要在应用程序设计中进行一些更改;不是吗?

标签: security authentication web-applications


【解决方案1】:

如果无法进行加密,您应该在客户端对密码进行哈希处理(使用服务器提供的随机盐)并比较生成的哈希。

这种方法有两个优点:

  1. 每次登录的哈希值不同
  2. 密码永远不会以纯文本形式发送。

但是,如果没有加密和正确身份验证,会话劫持和此类攻击是微不足道的。

请注意,如果没有在 http 之上的某种加密/身份验证层,就无法使这个足够安全,以阻止相当有能力的恶意方的任何攻击尝试,所以最好不要给用户任何虚假的安全感,mmkay?

“让我们只让登录尽可能安全”中最大的问题是会话侧劫持攻击在没有加密的情况下是相当微不足道的。 Sidejacking(定义在Wikipedia)是:

会话劫持,攻击者使用数据包嗅探来读取两方之间的网络流量以窃取会话 cookie。许多网站对登录页面使用 SSL 加密以防止攻击者看到密码,但一旦通过身份验证,就不会对站点的其余部分使用加密。这允许可以读取网络流量的攻击者拦截提交给服务器的所有数据或客户端查看的网页。由于此数据包括会话 cookie,因此即使密码本身没有泄露,它也允许他冒充受害者。 [3]不安全的 Wi-Fi 热点特别容易受到攻击,因为共享网络的任何人通常都能够读取其他节点和接入点之间的大部分网络流量。

【讨论】:

  • 非常感谢您的帮助;通过这种方式,我应该将纯密码(不是散列版本)存储在服务器上。这样对吗?我有点担心服务器上的通行证安全性。只是另一个;一开始就在用户通过传真的同时发送盐会更安全吗?
  • 关于 HTTPS,我认为最终由于缺乏安全性,我们必须为 web-app 启用它。
猜你喜欢
  • 1970-01-01
  • 2018-04-05
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2018-09-16
  • 2019-02-17
相关资源
最近更新 更多