我有一个通过安全/ SSL套接字连接到服务器的客户端应用程序。应用程序启动时，用户需要登录。现在我要求我需要将实际密码发送到服务器（通过SSL加密），而不是发送密码哈希的首选方法。话虽如此，我如何安全地将密码存储在客户端内存中，以便在客户端由于连接丢失而需要在幕后重新连接服务器时重新使用此密码？
我可以轻松加密密码，甚至可以将其放入KeyStore并在以后检索它以进行重新连接，但是，即使我这样做，在我看来，黑客可以检索密码，如果他有权访问该应用程序在调试器中。当需要在客户端暂时存储密码时，这只是生活中的事实吗？
是否有更好/首选的方法来实现相同的目标（即允许客户端重新连接到服务器而无需用户在初次登录后再次输入密码）？从服务器发送的过期登录令牌是否是更好的方法（我可以将此过期令牌传递回服务器而不是重新连接时的密码）？
最后，一般来说，当应用程序正确地“剥离”调试符号时，有人将调试器连接到Java桌面或Android上正在运行的应用程序是多么容易？我是否需要担心这种情况，或者Java是否会保护我的运输应用程序没有附加调试器或其他内存分析器？
答案 0 :(得分：1)
如果黑客可以在调试器中访问该应用程序，则可以检索密码。
正确。黑客在观看用户类型时也可以通过用他们的物理眼球查看用户的肩膀来访问密码。
黑客可以在用户计算机上存储键盘记录器后访问。
当需要将密码暂时存储在客户端上时，这只是生活中的事实吗？
没有。
另一种方法是亲自访问每个用户并告诉他们不要使用调试器来破坏安全性。
让我们考虑用户（知道密码）在调试器中激活应用程序以学习密码的用例。他们已经知道了。
在考虑用户启动在调试器下运行的客户端应用程序的唯一用例之后，我不确定安全性是否“已损坏”，因为他们已经知道密码。
我想亨利黑客有可能在调试器中启动应用程序，通过关闭电源将其隐藏在另一个显示器上，然后运行以获取真实用户并让他们在开发工作站上输入密码已关闭其中一个显示器。那是你在谈论的“在调试器中访问应用程序”的场景吗？
我甚至需要担心这种情况，
不是真的
或者Java会保护我的运输应用程序没有附加调试器或其他内存分析器吗？
不，Java不保护您的用户。常识可以保护您的用户。
如果调试器正在运行，则它们不应该使用计算机。
99％的情况下，他们不会启动调试器。
1％的时间，他们会不小心运行调试器 - 因为用户单击随机图标。其中1％实际上会使您的应用程序在调试器下运行。再次，通过单击随机图标。其中1％实际上会通过点击屏幕上的随机图标到达可以输入密码的地方。
可能发生用户可能以某种方式在调试器下运行您的客户端。但。由于他们已经知道了密码，因此无需担心密码。
这与中间人攻击或远程控制攻击完全不同。
如果有人对用户的计算机进行远程控制，则运行调试器并监视事务，这完全是分开的。这是由防火墙和操作系统阻止的。不是Java。
将其放入KeyStore并稍后检索重新连接
这就是你所能做的一切。您的应用程序无法阻止“连接调试器”方案。操作系统的工作就是提醒用户正在连接调试器。
如果您担心责任，请不要存储密码。责任结束。
答案 1 :(得分：0)
我会按照你的建议做，在服务器端创建某种会话令牌。将其与用户关联，然后将其发送回客户端。
取决于你的意思。我认为调试Java应用程序相当容易，即使它们被剥离了调试符号。如果它们被混淆，甚至可以调试它们。
答案 2 :(得分：0)
您无法对应用程序中的（系统范围）键记录器执行任何操作。因此，将密码存储在内存中存在风险，但风险低于会话令牌：
黑客可以使用伪造SSL /安全重新连接的恶意客户端并强制使用令牌。这种方法比将密码存储在内存中会带来更多风险。