我正在制作推特客户端，我正在评估保护用户登录信息的各种方法。
重要提示：我需要保护用户的数据免受其他其他应用程序的侵害。例如，想象一下如果机器人开始在用户桌面上运行的应用程序中窃取Twhirl密码或Hotmail / GMail / Yahoo / Paypal，会发生什么。
澄清：我之前没有'重要'部分就问过这个问题，但是stackoverflow的用户界面无助于稍后在Q / A对话中添加细节。
有什么想法吗？
答案 0 :(得分：13)
这是一个捕获22。要么每次都让用户输入密码，要么不安全地存储密码（混淆，加密，等等）。
解决这个问题的方法是让更多操作系统加入内置密码管理器 - 比如OS X的Keychain。这样您只需将密码存储在钥匙串中，操作系统就会保证其安全，用户只需键入1个主密码即可。 OS X上的许多应用程序（如Skype）使用Keychain来完成您所描述的内容。
但是既然你可能正在使用Windows，我会说只需要进行一些混淆和加密。我认为你可能对密码窃取机器人略显偏执;如果你的应用程序没有庞大的用户群，那么有人会针对它并且特别是试图窃取密码的可能性非常低。除此之外，他们还必须能够访问受害者的文件系统。如果是这种情况，他们可能有病毒/蠕虫，并且有更大的问题。
答案 1 :(得分：5)
我认为你错过了更大的图景：
如果桌面遭到入侵，那么你就是F＃*％ED！
要从程序中窃取密码，必须以管理员身份在系统上运行病毒。如果病毒已经实现了这一点，那么从您的程序中窃取密码就会降低它想要做的恶意事件列表。
答案 2 :(得分：5)
以纯文本格式存储，让用户知道。
这样，对于您取得的安全级别没有任何误解。如果用户开始抱怨，考虑 xor'ing在您的网站上发布的常量。如果用户继续抱怨，请在代码中“隐藏”常量并告诉他们安全性不好。
如果用户无法开箱即用，那么实际上他们所拥有的所有秘密数据都是由Evil博士知道的。无论是否加密都无关紧要。如果他们可以阻止邪恶的人，为什么要担心以纯文本形式存储密码？
当然，我可以在这里说出我的屁股。是否有研究显示以明文形式存储密码会导致比存储密码错误更严重的安全性？
答案 3 :(得分：4)
如果您正在制作Twitter客户端，请使用其API
Twitter非常好documentation，所以我建议你在做客户之前先阅读所有内容。与此问题相关的最重要的部分是您不需要存储密码，而是存储OAuth令牌。您需要使用xAuth阶段获取OAuth令牌，然后在必要时使用其他Twitter API和此OAuth令牌。
xAuth为桌面和移动应用程序提供了一种交换方式 OAuth访问令牌的用户名和密码。一旦访问令牌 检索，支持xAuth的开发人员应该处理登录和 与用户对应的密码。
如果您可以使用密码，则永远不会存储密码
使用OAuth可能发生的最糟糕情况是第三方（黑帽黑客）获得访问到该Twitter帐户但不是密码。这将保护那些天真地使用相同密码进行多种在线服务的用户。
使用某种钥匙串
最后，我同意应该使用预先制作的解决方案（如OSX的钥匙串）来存储敏感的OAuth信息，受感染的机器只会显示当前未锁定的钥匙串的信息。这意味着在多用户系统中，只有登录用户的密钥链才会容易受到攻击。
其他伤害限制
可能有一些我错过了谷歌的“最佳安全实践”，并开始阅读可能相关的内容。
编辑（响应所需的一般案例解决方案）
在没有用户输入的情况下，您希望访问在线服务。这通常意味着您最多可以通过Keychain等方式对身份验证凭据进行用户级访问控制。
我从未使用过OSX Keychain所以现在我将谈论SELinux。在SELinux中，您还可以确保这些身份验证凭据仅提供给您的程序。如果我们继续使用操作系统级别的东西，你也可以签署所有进程，从启动到加密，确保没有其他程序可以模仿你的程序。这一切都超出了典型的用户系统，并且考虑到这种级别的设置，您可以确保用户不会天真地受到攻击，或者系统管理员足够复杂。在这个级别，我们可以保护这些凭证。
让我们假设我们没有那么远地保护这些凭据，然后我们可以假设系统受到了损害。此时，身份验证凭据会受到损害，本地端的这些凭据的混淆/加密不会添加任何真正的安全性，也不会将部分或全部存储在第三方服务器上。这很容易看到，因为没有用户输入，您的程序需要自助引导以获取这些凭据。如果您的程序可以在没有输入的情况下完成，那么任何反转设计您的混淆/加密/服务器协议的人都可以。
此时它是损坏限制，不要将密码存储为身份验证凭据。使用OAuth，cookie会话，盐渍哈希等，它们都只是代表在过去的某个时刻你证明你知道密码的代币。在任何良好的系统中，这些令牌可以在活动会话期间被撤销，时间过期和/或定期交换新令牌。
令牌（无论形式如何）还可以包含其他非用户输入身份验证信息，这限制了您在其他地方使用它们的能力。例如，它可以封装您的主机名和/或IP地址。这使得在不同机器上使用凭证变得很困难，因为模仿这些形式的凭证需要访问适当级别的网络基础设施。
答案 4 :(得分：2)
经过进一步思考，我想我找到了一条路。我将对我的应用程序桌面应用程序使用ASP.net身份验证，在线存储他们的凭据，并让Internet Explorer的密码管理器为我处理这个辅助对或凭据的本地缓存。
首次登录时，我必须让他们通过类似Facebook的API进行身份验证。
答案 5 :(得分：2)
我不明白......为什么加密不好？使用大密钥并将密钥存储在计算机密钥存储区中（假设为Windows）。做完了。
答案 6 :(得分：0)
OSX：使用钥匙串
Windows：使用CryptProtectData和CryptUnprotectData
Linux：使用GNOME Keyring和KDE KWallet