11

我正在制作一个 twitter 客户端，并且正在评估保护用户登录信息的各种方法。

重要提示：我需要保护用户的数据免受其他应用程序的影响。例如，想象一下如果一个机器人开始从用户桌面上运行的应用程序中窃取 Twhirl 密码或 Hotmail/GMail/Yahoo/Paypal 会发生什么。

澄清：我之前在没有“重要”部分的情况下问过这个问题，但 stackoverflow 的 UI 对稍后在 Q/A 对话中添加细节没有帮助。

  • 散列显然不这样做
  • 以可逆的方式混淆就像试图躲在我的手指后面
  • 纯文本听起来很混杂
  • 要求用户每次都输入他的密码会使应用程序厌烦

有任何想法吗 ？

4

7 回答 7

13

这是第 22 条规则。要么让用户每次都输入他的密码，要么不安全地存储它（混淆、加密等等）。

解决这个问题的方法是让更多的操作系统加入内置的密码管理器——比如 OS X 的钥匙串。这样，您只需将密码存储在钥匙串中，操作系统即可确保其安全，用户只需输入 1 个主密码。OS X 上的许多应用程序（如 Skype）使用 Keychain 来完成您所描述的操作。

但由于您可能使用的是 Windows，我想说只是进行一些混淆和加密。我认为您可能对密码窃取机器人有点偏执；如果您的应用程序没有大量用户群，那么有人会针对它并专门尝试窃取密码的可能性非常低。除此之外，他们还必须有权访问受害者的文件系统。如果是这种情况，他们可能有病毒/蠕虫并且有更大的问题。

于 2008-10-22T14:05:31.813 回答
5

我认为您在这里错过了更大的图景：

如果桌面被入侵，你就是 F#*%ED！

要从您的程序中窃取密码，病毒必须以管理员身份在系统上运行。如果病毒已经做到了这一点，那么从你的程序中窃取密码就在它想要做的恶意事情的列表中。

于 2008-10-22T23:35:56.293 回答
5

以纯文本形式存储并让用户知道。

这样，就不会对您已达到的安全级别产生误解。如果用户开始抱怨，请考虑将一个发布在您的网站上的常量异或到它上面。如果用户不断抱怨，请“隐藏”代码中的常量，并告诉他们它的安全性很差。

如果用户无法将坏人拒之门外，那么实际上他们拥有的所有秘密数据都为邪恶博士所知。加密与否无关紧要。如果他们可以将邪恶的人拒之门外，为什么还要担心以纯文本形式存储密码呢？

当然，我可以在这里说我的屁股。是否有研究表明，以纯文本形式存储密码比将密码模糊存储更安全？

于 2009-05-26T04:01:29.927 回答
4

如果您正在制作 twitter 客户端，请使用他们的 API

Twitter 有非常好的文档，所以我建议你在做客户端之前阅读它。与此问题相关的最重要部分是您不需要存储密码，而是存储OAuth令牌。您需要使用xAuth阶段来获取 OAuth 令牌，然后在必要时将其他 Twitter API 与此 OAuth 令牌一起使用。

xAuth 为桌面和移动应用程序提供了一种将用户名和密码交换为 OAuth 访问令牌的方法。检索到访问令牌后，启用 xAuth 的开发人员应处理与用户对应的登录名和密码。

如果你可以逃脱它，你永远不会存储密码

使用 OAuth 可能发生的最糟糕的情况是第 3 方（黑帽黑客）可以访问该 Twitter 帐户，但不能访问密码。这将保护那些天真地为多个在线服务使用相同密码的用户。

使用某种钥匙串

最后，我同意应该使用 OSX 的钥匙串等预制解决方案来存储敏感的 OAuth 信息，受感染的机器只会泄露当前解锁的钥匙串的信息。这意味着在多用户系统中，只有登录用户的钥匙串才会容易受到攻击。

其他损坏限制

可能有一些我错过的东西，请使用 Google 获取“最佳安全实践”并开始阅读可能相关的内容。

编辑（响应 finnw 所需的一般案例解决方案）

您想要在没有用户输入的情况下访问在线服务。这意味着通常您最多可以通过 Keychain 之类的方式对身份验证凭据进行用户级别的访问控制。

我从未使用过 OSX 钥匙串，所以现在我将谈谈 SELinux。在 SELinux 中，您还可以确保这些身份验证凭据只提供给您的程序。如果我们继续进行操作系统级别的工作，您还可以对从启动到加密的所有进程进行签名，以确保没有其他程序可以模仿您的程序。这完全超出了典型的用户系统，鉴于这种级别的设置，您可以确信用户还不够天真而不会受到损害，或者系统管理员足够兼容。在这个级别，我们可以保护这些凭据。

让我们假设我们在保护这些凭据方面没有走得太远，那么我们可以假设系统受到了损害。此时，身份验证凭据被泄露，在本地对这些凭据进行混淆/加密不会增加任何真正的安全性，也不会将其部分或全部存储在第 3 方服务器上。这很容易看出，因为在没有用户输入的情况下，您的程序需要自行引导以获取这些凭据。如果您的程序可以在没有输入的情况下执行此操作，那么任何对您的混淆/加密/服务器协议进行逆向工程的人都可以。

此时是损坏限制，请勿将密码存储为身份验证凭据。使用 OAuth、cookie 会话、加盐哈希等，它们都只是表示在过去某个时刻你证明你知道密码的令牌。在任何好的系统中，这些令牌都可以被撤销、过期和/或在活动会话期间定期交换新令牌。

令牌（无论其形式如何）还可以包含额外的非用户输入身份验证信息，这会限制您在其他地方使用它们的能力。例如，它可以封装您的主机名和/或 IP 地址。这使得在不同的机器上使用凭证变得困难，因为模仿这些形式的凭证需要访问适当级别的网络基础设施。

于 2012-10-29T18:50:39.443 回答
2

经过进一步的思考，我想我找到了一种方法。我将为我的应用程序桌面应用程序使用 ASP.net 身份验证，在线存储他们的凭据，并让 Internet Explorer 的密码管理器为我处理这个辅助对或凭据的本地缓存。

我只需要让他们在第一次登录时通过类似 Facebook-API 的表单进行身份验证。

于 2008-10-22T14:19:06.090 回答
2

我不明白...为什么加密不好？使用大密钥并将密钥存储在机器密钥库中（假设是 Windows）。完成了，完成了。

于 2008-10-22T23:41:20.823 回答
0

OSX：使用钥匙串

Windows：使用 CryptProtectData 和 CryptUnprotectData

Linux：使用 GNOME 密钥环和 KDE KWallet

于 2014-06-14T02:10:22.270 回答